js/keywords: one source of truth for JavaScript keywords - #1562

Approving. Reviewed at 8441bd5, baseline origin/main = c3af487f ("Add task to split AGENTS.md into scoped documents (#1560)").

The risk in a DRY extraction like this is that the consumers were not actually identical — #1522's hex-codec extraction found DJS deliberately divergent, and #1533's sweep found a real divergence hiding as a latent bug. So I enumerated all three consumers' sets before and diffed them against the new shared lists.

Set diff — the three consumers, before vs after

Old sets parsed out of origin/main's sources; new sets taken from the exported lists (plus each consumer's own extras):

No set difference anywhere. No duplicates on either side. keywords is exactly reservedWords ∪ strictModeReservedWords ∪ restrictedNames ∪ {undefined}, sorted (38 + 8 + 2 + 1 = 49).

The rtti regrouping is the one that needed care and it lands correctly: false/null/true/void move out of its "predefined type names" comment-group into reservedWords, and yield moves out of its strict-mode group (the new strictModeReservedWords has 8 entries, no yield) into reservedWords — net zero. undefined correctly stays in rtti's own list, since reservedWords does not contain it and rtti does not spread restrictedNames. Re #1547: all nine TS strict-mode reserved words and intrinsic are present and accounted for.

Behavioural sweep across all three consumers

Set equality is not the same as behaviour equality, so I also drove each consumer's real entry point over 100 words — every keyword old and new, the TS predefined type names and type operators, TS contextual keywords that were never in any list (as, is, of, get, set, async, from, satisfies, asserts, declare, namespace, type, abstract, accessor, override, using, …), and near-miss identifiers (Await, AWAIT, awaits, yield2, let2, _, $, T0, …):

• js/tokenizer tokenize — full token stream, JSON-compared
• djs/tokenizer tokenizeJs — full token stream, JSON-compared
• types/rtti/ts dataToTs — whether a rule of that name keeps its identifier or gets a generated T<n>

Identical on origin/main and at this head for all 300 results. Negative control (perturbing yield's three results) diffs as expected, so the harness discriminates.

Type level

_KeywordToken went from a hand-written six-arm union to Exclude<typeof keywords[number], 'true' | 'false' | 'null' | 'undefined'>. I checked that against main's literal union with a [A] extends [B] ? [B] extends [A] equality inside the project's own tsc: exactly equal; adding one phantom kind to the old union makes it fail (TS2322), so the check is real.

_KeywordsPinned is not decorative either — appending 'zzz' to keywords gives module.f.mjs(65,21): error TS2344: Type 'false' does not satisfy the constraint 'true'. Good: it means the /** @type {JsToken} */ cast in the new keywords.map(…) cannot silently drift, because _KeywordToken is derived from the same list the cast reads.

Gates

• npx tsc --noEmit → 0. npm run prepack from a clean tree → 0.
• npm test → pass: 2709, fail: 0 vs main's 2708 — exactly the one new js/keywords proof.
• Emitted declarations read directly (not bin/extract.mjs): js/tokenizer/module.f.d.mts, djs/tokenizer/module.f.d.mts and types/rtti/ts/module.f.d.mts are byte-identical to main. The only surface change is the new js/keywords module itself, whose consts emit as precise readonly [...] tuples (not string[]). @module survives in the new declaration (1 occurrence, blank line after the header present); the single : any grep hit is the word "any" in prose.
• bin/linkcheck.mjs — broken-link sets identical to main.

Proof quality

proof.aggregate mutation-tested rather than trusted by name:

The third one is the useful one: it shows the DRY wiring is real, not just declared — a change to the shared list propagates into both tokenizers' behaviour. And pinning the sort order matters, since keywordEntries feeds ordered_map's fromEntries.

Minor

changelog/unreleased/1562.md ends with [#1562](…/pull/1562), but §8.3 now says entries carry "no PR number or link inside the file". Same drift I noted on #1564; most existing unreleased/ files still have links, so this follows the de-facto shape rather than the written rule.

Not an issue

• types.ts importing import type { keywords } from a .f.mjs introduces no cycle — js/keywords imports nothing from js/tokenizer.
• reserved in rtti widening from a const tuple to readonly string[] is invisible: it is module-local and the emitted declaration is unchanged.
• _KeywordsPinned is _-prefixed, correct under §6.2 (a JSDoc @typedef has no non-exported form).
• No README.md for the new module directory — fjs/js/tokenizer has none either, and I find no rule requiring one.

The consumers really were identical this time, and the extraction is faithful to all three.