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.
A teammate’s pull request adds a build queue. The build server keeps one queue for its whole life and hands it batches of jobs as they arrive; each job names its own preset and overrides. QA reports that jobs come out with another job’s settings, sometimes from an earlier batch, and that a batch whose first job names an unknown preset builds nothing at all. You are reviewing the pull request.
Jobs ship with the wrong mode, minification and directory, silently, and the mistake can come from any batch the server handled before. One bad job blocks every job behind it.
Reproduce One queue: queue.process([a: library]) then queue.process([b: library, production]). The second batch’s job should build a minified production library; today it builds like a.
Acceptance criteria Each job builds with its own preset and overrides, in every batch the queue handles. A job the factory rejects prints rejected with the factory’s reason, and the jobs after it still build. An empty batch prints (no jobs). Keep the cache only if it is right for every job it answers; otherwise remove it. Notes Each batch prints one line per job, “id: configuration → where main.js goes” or “id: rejected (reason)”, joined by “ | ”; a case’s batches are joined by “ || ”. Keep the queue’s type and its process method’s signature, and the Job type; the checker makes one queue per case and hands it each batch in turn.