spheredev
Implement multi-file Cellscript targets
In some cases it might be desirable for a single Cell target to produce multiple output files; for example a transpiler might produce both code and an accompanying source map. Writing additional files in a Tool right now will cause the auxiliary files not to be tracked. It would be nice if there were a way to track them.
Another case where this is sorely needed is TypeScript compilation. Because of the way CommonJS modules work, the TS compiler cannot concatenate sources, so it instead must create one .js output for each .ts input, and each of those needs to be tracked so that conflict detection, cleaning, and so forth work correctly. However it's not possible to split the job into multiple targets because TS treats the entire set of inputs as a unit for the purposes of type checking and module resolution.
I should note that implementing this isn't as simple as monitoring which files get written during tool execution: conflict detection requires that the set of inputs and outputs is fully known before performing the build. For that to work with multi-file targets there needs to be a pre-build step to allow each tool to assemble a list of output files it will create if the build is allowed to commence. The list can then be scanned for duplicates to find out if there are any conflicts.
Yep, it's on my to-do for mS 5.1. Its needed for source maps, as mentioned above, and I imagine there would be a lot of other uses too.
This didn't make it into miniSphere 5.1 as there were a couple important bug fixes I wanted to get out and I had already done some feature work necessitating a minor version bump, so 5.1 got released early.
That said: While I would like to tackle this for mS 5.2, it's not trivial and will almost certainly require a breaking API change to the Tool class. The Cellscript API is not yet frozen so breaking changes are allowed, but some thought should be put into any new API since--even without a formal API freeze--I want to minimize further breakage in any case.
I'm going to go ahead and reschedule this for miniSphere 6.0. I may implement it sooner, but it's going to need some thought as to the best way to set up the API so it shouldn't block 5.2, methinks.
This is a blocker for #75 (TypeScript support). The TS compiler takes only one file as input (usually tsconfig.json) and produces multiple output files. All output files need to be tracked in order for the compiler to know when it needs to run the compiler again.
It turns out I was over-thinking the conflict-detection thing. Conflict detection is a convenience to avoid running potentially expensive tooling if the build can be determined in advance to be impossible due to a target conflict. Conflicts are not destructive to the source tree, so this doesn't need to be perfect; if a particular conflict can't be detected until after tools have been run, so be it.