CI tests

One npm script

One command must run the whole suite. A test script in package.json compiles the project and runs the compiled tests, so every machine repeats the same steps with npm test. No tribal knowledge, no wiki page with five manual steps:

{ "scripts": { "test": "tsc -p tsconfig.json && node dist/tests/math.test.js" } }

npm test

pass: doubles two

Local runs and server runs now execute identical steps. When a test fails on the server but passes locally, the cause is the environment, not a forgotten flag.

Non-zero fails

A failing test must fail the command. An assert that throws makes Node exit with a non-zero code, and npm passes that code through, so npm test turns red exactly when a check breaks. Never silence this chain with fallback tricks or empty catch blocks around asserts:

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal

That block in the log names the broken expectation. The fix lands in the product code or in the test, and the next run decides the verdict.

Node versions note

Note the Node versions the project supports, and run the suite on each of them. A short support note in the readme names them, plus one server run per version. New syntax that older Node cannot parse is the usual surprise, and the matrix catches it before users do.

Keep the list short: the current LTS and the previous one cover almost every reader. Drop old versions openly with a note, instead of letting them rot in silence.

No merge on red

Make green tests a merge rule, not a suggestion. No branch merges while the suite is red: the rule is simple and applies to everyone, including urgent fixes. Red means stop, fix forward, and merge only when the run turns green again.

The rule protects the main branch around the clock. Every commit stays releasable, because no broken change ever lands on top of it.

Next: DOM basics

Article author: Arthur Isaev