deno

2d3f3f18 - feat(core): synthetic_esm extension DSL + node:worker_threads canary (#34038)

feat(core): synthetic_esm extension DSL + node:worker_threads canary (#34038) Adds a built-in `synthetic_esm` mechanism in `libs/core` so an extension can map a module specifier (e.g. `node:worker_threads`) to a backing polyfill script. On first import the loader evaluates the script (once — the result is cached) and synthesizes an ES module whose named exports are derived from `Object.keys` of the IIFE's returned exports object, plus a `default` export pointing at the object. This is Node's `BuiltinModule.getESMFacade` shape, but with the mapping declared by extensions and the dispatch driven entirely by `libs/core`, so it works for any extension that wants a CJS-shaped polyfill exposed as ESM. `load_ext_script` now caches its evaluated result so the synthetic-esm dispatch and other callers (CJS `require` through the JS-side `loadExtScript` wrapper) share one IIFE evaluation — re-evaluating a polyfill body would clobber registered `internals.__*` hooks and produce duplicate class identities. The cache is snapshot-serialized via `SnapshotDataId` so the dispatch can still find values evaluated at snapshot time. `node:worker_threads` is the canary because it is the only `*_esm.ts` wrapper today that needs live bindings — its `worker_threads_esm.ts` used `export let` plus an `internals.__refreshWorkerThreadsWrapper` callback to push `parentPort`/`threadId`/`workerData`/`isMainThread`/`resourceLimits` into the ESM facade after `__initWorkerThreads`. With this change the wrapper is gone: the polyfill's tail IIFE returns a data-property exports object, and `__initWorkerThreads` mutates those properties. The synthetic module is constructed lazily on first import, after bootstrap, so it snapshots the post-init values directly — no refresh op required.