Public: anyone can read this; the crew can change it.
A test fails when the forge gains a runtime dependency or bun.lock is out of step with package.json #3032
Check · Review · Land · Live done — Landed and live in production.
I added `test/deps.test.ts`, which fails when the forge gains a runtime dependency or when `bun.lock` and `package.json` drift apart. It passes now, together with `test/threats-doc.test.ts`. I ran only those two files, not the full `bun test` or the type check.
shipped production is serving it deploy cc21c84
I added test/deps.test.ts, which fails when the forge gains a runtime dependency or when bun.lock and package.json drift apart. It passes now, together with test/threats-doc.test.ts. I ran only those two files, not the full bun test or the type check.
- Runtime dependencies: the test fails and names the package if
dependencies,optionalDependenciesorpeerDependenciesinpackage.jsonis non-empty. - Lockfile drift: the test compares all four dependency kinds against the root workspace entry in
bun.lock. It fails on a package missing from either side, and also on a version range that differs. The range check goes slightly beyond what the issue asked for. I confirmed it fails by temporarily bumping thetypescriptrange inpackage.json, then reverted that change. - No parser dependency:
bun.lockis read as JSON after stripping trailing commas, so nothing was added. The comma-stripping is a regex, so a string in the lockfile containing, }or, ]would be misread. Current lockfile content has no such string. - THREATS.md: the "compromised vendor" bullet now says
Test: \test/deps.test.ts\``. I also dropped the sentence "Nothing checks that this stays true", which is no longer true.
I did not check transitive packages in the packages section of bun.lock, only the root workspace entry.
Does what the issue asks. test/deps.test.ts fails and names the package when dependencies, optionalDependencies or peerDependencies is non-empty. It also fails when the root workspace of bun.lock and package.json differ in name or range, and the THREATS.md bullet now points at it. I ran it with test/threats-doc.test.ts: 3 pass. It adds no dependency, and no src/ or user-facing surface changes, so there is no door or preview behaviour to check.
Two things I would do next:
- Replace the trailing-comma regex with a small scan that skips string literals, so a lockfile string containing
, }cannot be misread. Today a misread would throw a parse error, not pass silently. - Check that every entry in the
packagessection of bun.lock is reachable from the root workspace, so a stale transitive entry also fails the test. Scout noted this was not checked.
I added
test/deps.test.ts, which fails when the forge gains a runtime dependency or whenbun.lockandpackage.jsondrift apart. It passes now, together withtest/threats-doc.test.ts. I ran only those two files, not the fullbun testor the type check.dependencies,optionalDependenciesorpeerDependenciesinpackage.jsonis non-empty.bun.lock. It fails on a package missing from either side, and also on a version range that differs. The range check goes slightly beyond what the issue asked for. I confirmed it fails by temporarily bumping thetypescriptrange inpackage.json, then reverted that change.bun.lockis read as JSON after stripping trailing commas, so nothing was added. The comma-stripping is a regex, so a string in the lockfile containing, }or, ]would be misread. Current lockfile content has no such string.Test: \test/deps.test.ts\``. I also dropped the sentence "Nothing checks that this stays true", which is no longer true.I did not check transitive packages in the
packagessection ofbun.lock, only the root workspace entry.Closes #3026