AsyncLocalStorage changes, matching Node 24.22: - setTimeout, setInterval, setImmediate, process.nextTick and queueMicrotask callbacks run with the stores that were active when they were scheduled. Before, getStore() returned undefined in them. - An interval keeps that context on every tick, and a refreshed timer keeps it too. - enterWith inside one of these callbacks lasts until the callback returns. An enterWith in top-level code ends when the main module's body returns, and one inside a callback scheduled with no store active ends when that callback returns, so the store does not reach callbacks that were scheduled without it. Programs that enter stores (store.run, exit, enterWith, or a diagnostics_channel store binding) schedule through new *_als runtime entry points, which wrap a callback scheduled with a store active in a closure that installs the stores around the call. The emitter picks them from the new asyncContext runtime feature; other programs keep the plain entry points, so their scheduling is unchanged. The limitations page notes that completion callbacks of callback-style I/O APIs still run with no store. 5815-als-callback-context compares the stores each kind of callback sees with Node, plain and with SCRIPTC_SAN=1.
Node compatibility ledger
This workspace package owns scriptc's Node.js parity system.
node-v24.jsonpins the Node release tag, commit, and canonical docs/source inputs.static-support.jsonoverlays dedicated compiler paths and their internal test evidence on the compiler's generated surface manifest.generated/node-v24-internal.jsonis the engineering ledger, including implementation evidence and repository test paths.generated/node-v24-backlog.jsonis the internal tier-specific work queue. It separates verification, implementation, explicit-refusal replacement, and partial-surface audit work, and prioritizes stable Node APIs above experimental, deprecated, and legacy APIs.docs/src/generated/node-v24-compatibility.jsonis the stripped public artifact consumed by the docs website. It contains compiler-relevant runtime APIs, statuses, verification bases, and user-facing details; documentation, metadata, command-line/configuration entries, and rows that are N/A for native execution remain internal.
Statuses are evidence-aware: supported and partial require test evidence; refused requires an explicit compiler diagnostic or native throwing stub; not-implemented is the actionable backlog for an owned API family with no implementation match; by-design records an architectural exclusion; unreviewed still needs classification; and not-applicable is not a runtime API for that execution tier.
Run pnpm node-compat:backlog from the repository root for a summary. The filters --tier, --action, --priority, --chapter, and --status compose; use --format=json or --format=tsv for tooling.
Run pnpm node-compat from the repository root after changing the Node pin or the support manifest. pnpm node-compat:check is the offline drift/evidence gate; pnpm --filter @internal/compatibility check:upstream additionally verifies the pinned upstream inputs over the network.