First module.f.mjs file. - #1452

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e89cc9e6da

Approving. The risky part of this change is that a TS→JSDoc translation can silently weaken a type contract while the suite stays green, so I mutated rather than read.

Proof discovery is intact

npm test on this branch and on main, same machine:

main:   Number of tests: pass: 2354, fail: 0, total: 2354
second: Number of tests: pass: 2354, fail: 0, total: 2354

No proofs were lost to the rename — fjs/dev/module.f.ts already recognises .f.mjs, and proof.f.ts next to the renamed module still resolves it.

All three type contracts survive, each confirmed by mutation

• asserts v narrowing is live. A probe that returns a narrowed string | null compiles clean; strip asserts v from the JSDoc @type and it goes red with TS2322: Type 'string | null' is not assignable to type 'string'. The assertion signature really is carried by the @type annotation, not quietly dropped.
• assertNotNullish still returns T. The same mutation turns its own body red ('T | null | undefined' is not assignable to 'T').
• Assert<T> is still exported and still constrained. Assert<true> compiles; Assert<false> errors TS2344: Type 'false' does not satisfy the constraint 'true'. Worth confirming explicitly, since a JSDoc @typedef has no export keyword and it would be easy to assume the export was lost.

The other ~100 files are mechanical module.f.ts → module.f.mjs import rewrites.

Nit, non-blocking

assertNotNullish = (a, msg = undefined) adds a default the original msg?: unknown didn't have. It's a no-op — msg is already undefined when omitted — so it just adds a token. Fine either way.

One note: this is stacked on #1451, so it inherits the packaging point I raised there.

Re-verified at 1c6039da after the rebase onto the updated first. Still good.

• Nit addressed — assertNotNullish is back to (a, msg) with no redundant default.
• Proof count unchanged: npm test → pass: 2354, fail: 0, total: 2354, identical to main.
• The three type contracts still hold, re-confirmed by mutation on this head, not carried over from the last review:
  • probe relying on asserts v narrowing compiles clean; strip asserts v from the @type and it goes red (TS2322: Type 'string | null' is not assignable to type 'string').
  • the same mutation reddens assertNotNullish's own body, so its T return is still real.
  • Assert<true> compiles, Assert<false> errors TS2344.

The packaging point I raised on #1451 is resolved there (the rule was corrected rather than the code — see my comment on that PR), so nothing carries over to this one.