Files
scriptc/tests
Malte UblandClaude Opus 5.5 eb998d4f4d Key class fields and methods by symbols from CommonJS key tables
A JavaScript package often keeps its private symbols in one module,
`module.exports = { kClosed: Symbol('closed'), ... }`, and its classes
declare `[kClosed] = false` fields and `[kDispatch]()` methods with keys
destructured from that table (undici's core/symbols.js). Those keys were
not stable, so every such class was rejected, and with it every subclass
in other modules ("extending classes not declared in the program").

A property of a JS module's effective top-level `module.exports = {...}`
literal initialized with `Symbol(<constant>)` or `Symbol.for(<constant>)`
is now a stable class key, as a module-scope const is, provided nothing
before the table can run code (a require there could close a cycle and
publish the empty initial exports object), no earlier property can run
code, and nothing writes the property or replaces it through `exports`.
The property's own declaration symbol is the identity every requirer
shares, and the table's export global supplies the runtime key for
dynamic lookups (a base method calling a subclass's symbol-keyed method).

The checker types such keys as plain `symbol`, so it answers `this[k]`
with the union of every symbol-keyed property of the class. Reads through
table keys in JS files now take the field's own layout type.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-19 13:18:13 -07:00
..