JavaScript intermediate taught ES modules. In this download, map-limit.js exports mapLimit and TaskError; main.js imports the public function and demonstrates its output. package.json has type:module so Node treats .js files as ES modules. No installation is required because there are no dependencies.
Extract task-pool.zip, open a terminal inside task-pool and run npm start, then npm test. These are shell commands, not statements to paste into a console editor. Start prints 30,10,20. Tests report six grouped cases; each group contains several assertions and input cases.
The real module entry uses top-level await, which Node supports for ES modules. The existing JavaScript lesson editor instead uses async main() followed by main() because its runner initially parses a classic script. Preserve that wrapper for in-page async examples. The algorithm is the same; the entry point differs.
A reusable package also needs an environment policy. This teaching project targets modern browsers and Node 22+ and relies on AbortController, Error cause and performance.now. Publishing and compatibility with older engines are separate work; do not imply the download is a production package release.
Predict, run, and explain
Write the output and trace the important state changes before checking it. Then run the program. Each editor is independent. Async examples end with main() so this editor waits for their work.
const files = [
"map-limit.js",
"main.js",
"pool.test.js",
"package.json",
"README.md"
];
console.log(files.length);
console.log(files.includes("map-limit.js"));Check your prediction
5
true Follow source, entry point and tests separately
Open map-limit.js for the library contract, main.js for one caller and pool.test.js for controlled schedules. The demo chooses input and prints results; the library owns concurrency and cleanup. A successful demo is not evidence for every schedule. Keep its entry convention separate from the browser editor: Node ES modules can await at top level, while the classic-script editor uses async main followed by main().
| Boundary or case | What to inspect |
|---|---|
| Demo | Expect ordered output without a live service |
| Tests | Inspect a held callback and source finally fixture |
| Edits | Keep source, combined listing and archive synchronized |
Change only a demo input and predict its new result. Then identify the exported-function test catching a completion-order implementation. Keep generated output and dependencies outside authored source and rebuild the public archive after source edits.
Your turn
Modules & Local Use: practise
Write a small public API description as a record with name, resultOrder and cancellation fields. Print mapLimit, input, and cooperative. Then compare it with the download README and identify where each claim is tested.
// Use accurate words, not a claim that cancellation can force arbitrary work to stop.Hint 1: the idea
Documentation is part of the caller contract.
Hint 2: a first step
Name the ordering rule independently of when operations complete.
Show one solution
const api = {
name: "mapLimit",
resultOrder: "input",
cancellation: "cooperative"
};
console.log(api.name);
console.log(api.resultOrder);
console.log(api.cancellation);mapLimit
input
cooperativeExplain why the implementation meets the stated contract. Which part is enforced by the language or checker, and which part needs behavioral evidence?
Change it and test it
Run the download locally if possible, then change only main.js to use limit 1. Keep tests intact. Explain how you would tell a caller about finite-input and retained-output limits before they try a huge or infinite source.
Completion is saved in this browser only. It does not measure mastery.