fix(ext/node): single source of truth for emulated Node version#35273
Merged
Conversation
process.version / process.versions.node were hard coded as string literals in the node:process polyfill, separate from any value the rest of the runtime could reference, so the reported Node version had to be kept in sync by hand. Define the emulated Node version once as NODE_VERSION in ext/node, and have the polyfill carry a __NODE_VERSION__ token that is substituted with that constant at snapshot build time. Rust code can now read the same constant directly, so the reported version no longer needs hand-syncing with a duplicated literal.
bartlomieju
added a commit
that referenced
this pull request
Jun 16, 2026
The NODE_VERSION constant, the process.version polyfill token, and the snapshot-time substitution are factored out into #35273 so this PR stays focused on the engines.node/engines.deno warning. This branch now only consumes deno_node::NODE_VERSION (re-exported as deno_lib::version::NODE_VERSION) for the engines check, and depends on #35273 landing first.
bartlomieju
changed the title
napi_get_node_version() hardcoded 20.11.1, so native addons calling it saw a Node version unrelated to (and far behind) the one reported through process.version / process.versions.node. Derive major/minor/patch at compile time from deno_node::NODE_VERSION, the single source of truth, so the C-ABI value can no longer drift from the JS-visible version. The napi test now asserts napi_get_node_version() equals process.versions.node instead of just checking major >= 1.
bartlomieju
enabled auto-merge (squash)
June 16, 2026 21:16
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
process.version/process.versions.nodewere hard coded as stringliterals in the
node:processpolyfill, with no value the rest of theruntime could reference, so the reported Node version had to be kept in sync
by hand whenever it was bumped.
This defines the emulated Node version once as
NODE_VERSIONinext/node/lib.rs, and has the polyfill carry a__NODE_VERSION__token thatis substituted with that constant at snapshot build time (in
maybe_transpile_source). The substitution runs for both the snapshot buildand any non-snapshot runtime, and
_process/process.tsis a lazy-loadedscript that passes through the transpiler, so the baked value is correct
everywhere. Rust code can now read the same constant directly instead of
duplicating the literal, so the reported version can no longer drift.
napi_get_node_version, exposed to native addons through the Node-API CABI, previously returned a hard coded
20.11.1that was unrelated to and farbehind the emulated version. It now derives its major/minor/patch from the
same
NODE_VERSIONconstant at compile time, so addons calling it observethe same version as
process.versions.node. The napi test asserts the twoagree.