TS => MJS. Iteration 6 - #1460

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Approving. Clean single-module migration: fjs/types/bit_vec as a proper rename (no stray add-without-delete), CHANGELOG entry present, npx tsc clean, npm test → pass: 2354, fail: 0, total: 2354.

No export loss. I checked this the reliable way rather than by pattern-matching the source — importing all 24 names that main exports, from the new .mjs, compiles clean. (A regex comparison suggested BitOrder, PopFront, Reduce, Unpacked and Vec had gone missing; they hadn't — the typedef form just doesn't match the same pattern. Worth saying explicitly so it isn't mistaken for a finding.)

Type visibility — the largest instance so far

Six types declared without export in the .ts are public as JSDoc typedefs:

Norm  NormOp  Base  UnpackConcat  ListToVecState  ListToVecOp

Verified both directions — 6 errors importing them from module.f.ts on main, 0 errors importing them from module.f.mjs here.

Same non-blocking observation as Fn (#1453), X (#1454) and NotLazy/Empty/Concat (#1458), and I'm not asking you to change anything in this PR. But the running total is now 11 previously-private types promoted to public API across four iterations, and this batch is the least comfortable: Base, Norm and ListToVecState are internal implementation vocabulary — Base especially is a name you'd want available for something else later.

Since these are genuinely invisible in review (nothing errors, nothing fails, the diff looks like a faithful translation), they'll keep accruing silently for the rest of stage 1. A line in the migration doc settling it once — "unexported type aliases become public on migration; accepted" or "audit and re-privatize before stage 1 closes" — would cost less than deciding it per module, and would give a later cleanup pass something concrete to work from.

CI was still mid-run when I checked (15 pending, 1 neutral, 3 green); I'd expect it to settle, given the local suite is green.

What if we agree on conventions: if a type has the _ prefix, then we can consider it a private type, and changing such a type shouldn't be considered a breaking change?