Proposal: introduce Wireit plugins

[kwangure]

One huge limitation to Wireit currently is configuring input and output files. It's pretty easy for glob patterns of file inputs and outputs and the actual tool configuration to get out of sync. It's also not uncommon slightly to over include or under include file inputs and outputs. And when you fix a misconfiguration in one package, you may not notice it or remember to do it in another.

The fortunate bit is TypeScript knows what files it processes and where it puts them based on my configuration, so does ES Lint and Rollup...you get the picture. It would be handy if you could optionally use Wireit plugins that read that your tool configuration and configure files and outputs so that you don't have to. They could also configure other reasonable defaults. For example, TypeScript could default to only clean if files are deleted when in incremental mode.

This could also improve fingerprinting for commands by not ignoring caches when the repo-wide lock file changes. An ES Lint plugin could re-run only if the exact version of eslint or it's plugins changes...rather anything in the lock file being updated.

[aomarks]

Thanks @kwangure. How would you feel about a tool that automatically maintained your wireit config by synchronizing it with your tsconfig, rather than being a plugin that runs every time wireit does?

[kwangure]

It might be an acceptable compromise if it helps keep Wireit simpler.

That said, I'd probably add said tool as a Wireit command...and make it a dependency of every tsc command in order to maximize its utility. At which point I'd be wishing Wireit just did that for me under the hood.

[luke-lacroix-healthy]

So, I could do as proprosed and create a bash or Node script which updates the wireit section of the package.json. However, would wireit even see that? For example:

1. the compile script depends on the update-wireit script
2. the update-wireit script updates the dependencies of the compile script
3. wireit won't see the updated dependencies, AFAIK

Basically, developers would have to run the compile twice or know to run the update-wireit script before running the compile.

A plugin system would give us the ability to simplify repetitive tasks by allowing them to be shared across packages and repositories. I have to put the same scripts across some 30+ packages in this mono-repo and that is difficult to maintain.
Alternatively, if wireit supported a .wireit.js file instead of only the wireit section in the package.json, that could fulfill my needs to be able to generate the definition through code instead of through static data alone.

[deebloo]

what if instead of plugins (which tend to be a fragile part of any ecosystem) wireit publishes a public API. For example I know it doesn't ship the type definition files at the moment. A published API would make experiments like wireit-visualizer pretty straight forward and then folks could build on TOP of wireit rather than having code run through it. Even better if this api provided a way to update the config for your different commands. Then you could just run these separate tools that use the internals. Keeps the mess out of the core