Plugin System

Every new feature means editing the core

Built-in features live in one growing switch. Add a feature → reopen the core, risk merge conflicts, and hope nobody else touched that function too.

function renderToolbar(type) {
  switch (type) {
    case 'bold':  return applyBold();
    case 'emoji': return applyEmoji();
    case 'count': return wordCount();
    // new feature? edit this switch again…
  }
}

Interface + Registry + Factory

A Strategy-shaped Plugin interface is what the core calls. A registry collects registered plugins. A Factory instantiates them from config. The core just iterates — it never names a concrete plugin.

interface Plugin { name; run(ctx) }

class Registry {
  plugins = [];
  register(p) { this.plugins.push(p); }
}

// Factory builds a plugin from config
registry.register(pluginFactory.create('bold'));
// core never changes — it just iterates:
registry.plugins.forEach(p => p.run(ctx));

Run the core — only registered plugins react

The core calls run(ctx) on every enabled plugin, in registry order. Register a brand-new plugin at runtime — the core code above never changes.

Tip: click a plugin to disable/enable it, then run again.

Extend without touching the core

• Open/Closed: new features arrive as plugins — the core file never opens for edit.
• Third-party ecosystems: anyone can ship a plugin against the stable interface.
• Enable / disable / reorder plugins at runtime through the registry, no redeploy.
• You already use it: VS Code extensions, browser add-ons, webpack/babel plugins, WordPress.
• Caution: the plugin API must stay stable and versioned, and untrusted plugins need sandboxing — a bad plugin can crash or compromise the host.