fix: hand Node.js' null source back as null; cover the load hook's dependency and addon edge cases

[Brooooooklyn]

Follow-up to #764 (now on main), for the notes left in its review. Two commits.

Summary

transform_output                                   register.mjs
  no-source arm ─► source: None ─► undefined        startsWith("commonjs") also matched
  addon translator asserts === null ─► throws         commonjs-typescript ─► null ─► throws
  fix: Some(Either4::D(Null))                        fix: === "commonjs" (JS + Rust guard)

LoadContext.format: Either<String, Null>
  Node passes format: undefined for an unknown extension (.node under
  node_modules, flag off) ─► napi "Missing field `format`"
  fix: Option<…> so Node's own ERR_UNKNOWN_FILE_EXTENSION shows

The first and third are pre-existing on both hook paths (shared code); only the startsWith came in with #764.

Tests — register-hooks.spec.ts, 20 cases: local .node import (with and without --experimental-addon-modules), require() of a .node, latin-1; dependencies × OXC_TRANSFORM_ALL false/true set in-spec: addon with the flag, addon following Node's default (loads on ≥ 24.19 / ≥ 26.5, ERR_UNKNOWN_FILE_EXTENSION otherwise), latin-1, .cts and .mts → Node's own ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING; --conditions=require|import in both directions. Failing cases also assert neither ERR_INVALID_RETURN_PROPERTY_VALUE nor Missing field appears.

CI — test-linux-binding gains Node 26 (armv7 excluded: node:26-slim ships no arm/v7 image, same as 24), so the synchronous path runs on every OS in the matrix.

Test plan

• Full suite 95/95 on v22.23.2, v24.11.1, v26.9.0 (direct vitest; local pnpm test resolves Vite+'s bundled 24.x and only exercises the fallback)
• Spec alone on v24.21.0 (default-on addon branch on the 24 line) and with an outer OXC_TRANSFORM_ALL=true
• Each new test red before its fix, green after
• Rebased onto main after fix: register module hooks synchronously on Node.js >= 26.2.0 #764 landed; cargo clippy -D warnings, cargo fmt --check, cargo test, vp check
• CI green across the 22/24/26 × transform-all matrix on all hosts

Generated with Devin

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_000d841b-c0b8-4588-a77a-7b7b66b05f32)

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-18T07:04:26.791095Z	ba923c2	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_ffd3dffa-6c7e-4f58-8f61-5fa5a48a8fc1)

[chatgpt-codex-connector]

💡 Codex Review

oxc-node/packages/core/register.mjs

Line 157 in ba923c2

registerHooks({ load, resolve });

Preserve later asynchronous resolve hooks

When a process imports this registration module and subsequently installs another loader with module.register(), the synchronous hook always runs before that asynchronous chain. Because createResolve() short-circuits every specifier it successfully resolves, the later loader's resolve hook is never called for ordinary local/package imports, so loaders that redirect or annotate those imports silently stop working on Node.js ≥26.2.0; with the previous asynchronous registration, the later hook wrapped this one and could perform that resolution first. The synchronous path needs to preserve composition with subsequently registered asynchronous loaders rather than short-circuiting them.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Brooooooklyn]

Re the Codex P2 on registerHooks({ load, resolve }) — checked it against real binaries rather than taking it as read, with --import @oxc-node/core/register --import ./later-loader-register.mjs where the later loader is a plain module.register() loader that logs what it sees:

Node 26.9 (oxc = sync, later loader = async)      Node 24.11 (both async, later wraps oxc)
  [later resolve] file:///…/dyn.mts                 [later resolve] ./dyn
  [later load]    source len 28  (raw .mts)         [later load]    source len 989 (oxc output)
  extensionless: 5                                  extensionless: 5

So the claim as stated is not right: the later loader's resolve is called for every ordinary import — createResolve short-circuits but still hands the resolved URL down the chain. What changed is the position: it now receives the resolved file: URL instead of the raw specifier, and its load runs inside oxc-node's rather than around it. That is how Node.js orders things — ModuleLoader.resolve → resolveWithHooks, whose terminal nextResolve is the async hook chain — and it applies to every loader that moves to registerHooks(), which is what DEP0205 asks for. The only way for a synchronous hook to "preserve composition" would be to call nextResolve(specifier) first and use oxc-node's resolver only on failure, which reverses this loader's resolution precedence (tsconfig paths, the .js → .ts alias when both exist) — a product decision about #764's design, which is already on main, and not a defect in this PR; the flagged line is unchanged here.

Not acting on it in #767. If chaining with other module.register() loaders is something we want to guarantee, that's a README note ("register oxc-node's hooks last" no longer changes the order on ≥ 26.2) or a separate discussion, not a fix here.