npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@kaelan/with-plugins

v0.0.2

Published

A drop-in plugin system for your library's configuration objects.

Downloads

6

Readme

with-plugins

A type-safe, dead-simple, drop-in plugin system for JS/TS configuration objects -- whether it's for your own library/package/SDK, or someone else's. Oh and it's tiny -- literally a few lines of code.

Install

npm install @kaelan/with-plugins

Docs

Inspired by Payload CMS' simple plugin system, the withPlugins function simply receives a config object, and an array of plugins, where each plugin is a user-defined function that receives the config object and returns a modified version; each plugin is run sequentially, where the modified config is passed into the next plugin, and so on, resulting in a final plugin-modified config.

Obviously it's up to your library/package/software to process the plugin-modified config accordingly.

Example:

import featuredImagePlugin from "package-xyz";
import pluginWithOptions from "package-abc";

const config = withPlugins({ // your package's config object:
  fields: [{ name: "title", ... }, ...],
  optionX: true,
  ...
}, [ // plugins array:
  featuredImagePlugin, // a plugin that injects a "Featured Image" field into the base config's `fields` array
  pluginWithOptions({
    ...
  }), // you can make your plugin accept its own config object
  (incomingConfig) => {
    return {
      ...incomingConfig,
      fields: [...incomingConfig.fields, { name: "plugin_field", ... }]
    }
  } // you can write your own plugins inline
])

Many packages may wish to bundle with-plugins as a dependency and provide their own abstraction around it, rather than making their end-users install it directly. Here's an example where your custom package could provide a different end-user API while still using withPlugins under-the-hood:

import { buildConfig } from "your-package";

const config = buildConfig({
  fields: [{ name: "title", ... }, ...],
  optionX: true,
  ...
  plugins: [ // same as previous example, but "plugins" is a built-in property of your package's config object
    featuredImagePlugin,
    pluginWithOptions({
      ...
    }),
    (incomingConfig) => {
      return {
        ...incomingConfig,
        fields: [...incomingConfig.fields, { name: "plugin_field", ... }]
      }
    }
  ]
})

// ========================================================
// in `your-package/buildConfig.ts`
import { withPlugins, Plugin } from "@kaelan/with-plugins"

export interface PackageConfig {
  fields: Field[];
  optionX: boolean;
  ...
  plugins?: Plugin<PackageConfig>[];
}

export async function buildConfig(config: PackageConfig): Promise<PackageConfig> {
  if (Array.isArray(config.plugins)) {
    const configAfterPlugins = await withPlugins(config, config.plugins);
    return configAfterPlugins;
  }

  return config;
}

Note the usage of the Plugin generic type in the PackageConfig interface above.

Building plugins with their own config objects

In the above examples, the second plugin accepts its own config object. Here's the recommended design pattern for implementing this (TLDR: a function that returns a plugin function):

import { PackageConfig } from "your-package"

export interface PluginOptions {
  ...
}

export const pluginWithOptions =
  (options: PluginOptions) => (incomingConfig: PackageConfig) => {
    // optional custom logic here
    return {
      ...incomingConfig,
      // config customizations here
    };
  };

Feedback

Consider this project in beta -- it's young and its APIs may change. I'm curious to hear if anyone has use cases that with-plugins can't currently handle (create an issue).