perf(ext/node): convert node:util, node:assert to lazy-loaded - #33876

Mechanical scope is well-handled — 35 files updated, the 15 import ... from "node:util" and 16 import ... from "node:assert" callsites in ext/node/ consistently swapped to core.loadExtScript(), and the lazy_loaded_esm wrapper structure mirrors the established pattern.

Heads-up on the process.getBuiltinModule identity contract — this is the same surface that broke #33875 (which I REQUEST_CHANGES'd minutes ago). The test plan correctly verifies node:sys === node:util for CJS, but that's the CJS-CJS identity. The contract that bit #33875 was CJS-vs-ESM:

// parallel/test-process-get-builtin.mjs:57
assert.strictEqual(process.getBuiltinModule(id), imported.default);

Walking through the new util.ts IIFE shape:

const defaultExport = { format, formatWithOptions, ... };  // object literal A

return { callbackify, debuglog, ..., default: defaultExport };  // object literal B (B.default = A)

And the consumer paths:

• CJS process.getBuiltinModule("util") → loadNativeModule returns nodeMod.exports = nativeModuleExports.util = the IIFE's outer return = B ({ callbackify, ..., default: A }).
• ESM (await import("node:util")).default → util_esm.ts's export default mod.default = A ({ format, ... }).

B and A are different objects. CI is still pending (12 builds + others), but if test-process-get-builtin.mjs runs at HEAD I'd expect the same node_compat (3/3) failure as #33875.

Two ways to make the test pass

1. Make the CJS path return mod.default — change 01_require.js's const util = ... to use mod.default instead of mod. Cleanest fix: keeps the require system aligned with ESM's default semantics.

2. Make the IIFE's outer return the same object as defaultExport — restructure util.ts so defaultExport is the return, then B === A. Requires putting all named exports onto the same object that's referenced by default, which is roughly Node's actual shape (util and util.default both point at the same module-exports object).

Option 2 is the more principled fix and matches Node's behavior better. It's also what the original (pre-conversion) util.ts likely did.

CI

54 success, 12 pending, 0 fail at this HEAD (CI just started). Will re-confirm — flagging now since the bug pattern matches #33875 and you can probably catch it before the test-process-get-builtin shard reports.

LGTM — f532e702 (fix: remove defaultExport from util.ts and fix sys_esm.js for lazy ESM) takes option (2) from my prior comment exactly: restructured so the IIFE's outer return is the default object instead of building a separate defaultExport literal that was a different identity.

What I verified

util.ts: removed the 26-line defaultExport = { ... } literal entirely, and removed default: defaultExport from the IIFE's return. The IIFE now returns one single object containing all the named exports. ✓

util_esm.ts: export default mod.default → export default mod. Now the ESM-side default export is the same object the CJS side sees via core.loadExtScript("ext:deno_node/util.ts"). ✓

sys_esm.js: re-exports from node:util directly (was util_esm.ts). Cleaner — node:sys is a thin alias and Node's identity contract require("sys") === require("util") flows through the public alias rather than going through both lazy_loaded_esm wrappers. ✓

This means process.getBuiltinModule("util") === (await import("node:util")).default should now hold — the test that broke #33875 with the same pattern. CI confirms: 129 success, 4 pending, 0 fail. The previously-failing test-process-get-builtin.mjs is in the green set.

The 4 pending are slow test specs / wpt release linux-x86_64 shards — they don't exercise the identity contract. Substance is unambiguously correct.

Good follow-through on the design pattern after the #33875 / #33873 iterations clarified what default semantics need to look like for the lazy_loaded_esm <-> CJS bridge.