Many of the most popular file conversion utilities with a command-line interface (CLI) take the shape of one "monolithic" tool, with a great number of supported input and output formats baked in but no possibility to add other formats via plugins.
I'd been puzzled by this, considering that such tools seem like "obvious" candidates for a plugin-based architecture. Here are some findings after actually trying to make a plugin-based tool.
| Topic | Monolithic | Plugin-based |
|---|---|---|
| Examples | Pandoc, ImageMagick convert, ffmpeg1 | ? |
| Ease of contributing new formats | ❌ High barrier: Must go through maintainer of main repo, may take a while to review, may be rejected for niche or in-development formats | ✅ Low barrier: Can publish plugins completely independent of main repo |
| Download size / installed size on user system | ❌ Potentially large to cover all possible formats | ✅ Entirely controllable by user, who may choose to only install needed plugins or opt for a "full" installation containing all/most of them |
| CLI option collisions | ✅ Not possible because all options are known & maintained in main repo |
❌ Possible unless plugin authors cooperate (e.g. noting down option
names they use in central registry) or unwieldy "fully-qualified"
option names with unique prefixes are used (e.g. using centrally
registered names: PyPI package names, GitHub user/repo
strings, etc.)
|
| CLI options used by more than one format | ✅ Easily introduced (same reason as above) | ❌ What is the "source of truth" for their CLI help text etc.? Main repo means we're back to monolithic architecture, format-specific plugin repos seems arbitrary & may introduce conflicts. Only "clean" place is separate plugin that only exists to introduce the option; quite unwieldy |
| Intermediate representation | ✅ Can be altered at will if required by certain formats | ❌ Must either be very carefully chosen to cover all possible plugin needs, contain complicated extension mechanisms, or suffer from the usual choice of working around a subpar format vs breaking backwards-compatibility |
| Reproducibility for CLI users | ✅ Relatively simple for them to ensure: pin version of executable | ❌ Must pin version of tool itself plus all installed plugins; depending on exact plugin mechanism, mere presence of another plugin may alter behavior, so reproduction must ensure no additional plugins are present |
| User effort to install new format plugin | ✅ Not applicable since not plugin-based |
❌ Some effort required if "minimal" installation chosen;
0️⃣ Usually small, especially when using language with plugin mechanism built into packaging ecosystem (e.g. Python entrypoints, making plugins installed via Pip etc. automatically discoverable) |
1 ffmpeg does seem to have support for external libraries that add formats, but they must be baked in at compile-time.