forge.json names bun test as the check the forge runs against every push. Bun strips types; it
never checks them. So today a wrong type deploys and the check is green — on a tree that is about
1,900 lines of TypeScript with roughly 1,600 more in flight across three open branches.
Done looks like
[ ] tsconfig.json at the root: strict, plus what Bun's runtime needs
(moduleResolution: "bundler", allowImportingTsExtensions, noEmit, types: ["bun"]).
Nothing in it is loosened to make the current tree pass.
[ ] The tree typechecks clean. Where it does not, the code is fixed rather than the config; a
@ts-expect-error needs a sentence beside it saying why, and ideally there are none.
[ ] The check covers both: forge.json's test runs the typecheck and then bun test as one
command, and package.json carries the same as a script so a person runs exactly what the forge
runs.
[ ] Proven, not assumed: a deliberate type error makes the command fail and removing it makes it
pass. Say in the pull that you did this.
[ ] If a typechecker is added as a dev dependency, one line in the README says why it earns its
place; if it is done without one, the pull says how.
Filestsconfig.json (new), forge.json, package.json, README.md, and whatever the first
clean run turns out to need.
Risks The order is the cost here. Three branches are open (#19, #20, and #7's); a tsconfig.json
that lands first is nearly free, and one that lands last means fixing everyone's types at once. If
strict lights up more than a handful of places, land the config with the fixes and do not weaken
it — a strict: false config is worse than no config, because it looks like a check from the outside.
forge.jsonnamesbun testas the check the forge runs against every push. Bun strips types; it never checks them. So today a wrong type deploys and the check is green — on a tree that is about 1,900 lines of TypeScript with roughly 1,600 more in flight across three open branches.Done looks like
tsconfig.jsonat the root:strict, plus what Bun's runtime needs(
moduleResolution: "bundler",allowImportingTsExtensions,noEmit,types: ["bun"]). Nothing in it is loosened to make the current tree pass.@ts-expect-errorneeds a sentence beside it saying why, and ideally there are none.forge.json'stestruns the typecheck and thenbun testas onecommand, and
package.jsoncarries the same as a script so a person runs exactly what the forge runs.pass. Say in the pull that you did this.
place; if it is done without one, the pull says how.
Files
tsconfig.json(new),forge.json,package.json,README.md, and whatever the first clean run turns out to need.Risks The order is the cost here. Three branches are open (#19, #20, and #7's); a
tsconfig.jsonthat lands first is nearly free, and one that lands last means fixing everyone's types at once. Ifstrictlights up more than a handful of places, land the config with the fixes and do not weaken it — astrict: falseconfig is worse than no config, because it looks like a check from the outside.Fits Vesper's brief.