One build runner, three callers, then a queue
The repository from the lesson: a CLI, a watch task and a release task each need a configuration for the same build runner, and the team keeps one setting, the output root, that decides where builds go by default. Each level starts from the previous level’s finished code, so you can begin at any of them.
The repository gains a background worker bundle, built like a library but for Node 22. Workers are deployed by uploading their bundle to the workers storage bucket, not by writing it to a directory; every other preset keeps writing files. The CLI, watch task and release task must not change.
Today the worker preset is rejected. If every caller learns which presets upload and which write files, the next preset or output means editing all of them again.
Reproduce resolveBuildConfig("worker", {}) should give a development node22 esm build, and createOutput("worker", config).write("main.js") should be upload://workers/main.js. Today the worker preset is rejected.
Acceptance criteria A worker preset builds ESM for node22, into the output root’s worker directory unless the caller chooses one; library and app are unchanged. The output factory returns an upload to the workers bucket for the worker and a file output in the build’s directory for every other preset. A worker caller’s own directory still wins in its configuration (local build files go there), but its bundle uploads regardless: where the bundle goes is the output factory’s choice, by preset. Callers that ask for a configuration do not need to know which kind of output they get. No caller changes. Notes Cases print the configuration (mode, target, format, minify, output directory), then where main.js goes, or rejected. Keep the factories’ and the callers’ names and signatures; the checker calls them.