GeezerVison

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#unit-testing.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

The iOS and Android runtimes resolve ns:<name> builtin modules (ns:util, ns:module, ns:runtime, ns:url, ns:worker_threads, …) and a few node:<name> compatibility shims themselves, before any file or npm resolution. Neither bundler lets these imports through:

• webpack treats ns:util as a URL scheme, which skips resolve.alias, and fails with UnhandledSchemeError. node:* fails the same way, because externalsPresets.node is off.
• Vite fails with Rolldown failed to resolve import "ns:util", and silently replaces node:url / node:util / node:worker_threads with an empty browser stub. Under HMR, several dev-server passes also rewrite or stub these specifiers: /@id/ wrapping, routing to /ns/m/node_modules/ns:util, the esbuild dependency bundles, the dev import map, and the CommonJS require shim.

What is the new behavior?

Every ns: import is left verbatim in the output. Specifiers are matched by the ns: prefix, so modules added in future runtime versions work without changes here. ESM output keeps import … from "ns:util"; CommonJS output keeps require("ns:util").

Customization uses each bundler's own mechanisms:

webpack: the base config registers NativeScriptBuiltinModulesPlugin (default include: [/^ns:/]).

• Change its include list with webpack-chain: config.plugin('NativeScriptBuiltinModulesPlugin').tap(...).
• The plugin matches on the request after beforeResolve, so a stock NormalModuleReplacementPlugin can:
  • redirect a builtin to a polyfill (/^ns:url$/ → a file);
  • forward a bare name to a runtime shim (/^worker_threads$/ → node:worker_threads).

Vite: the base config adds nativescriptBuiltinModules().

• Add another instance with { include: ['node:worker_threads'] } to opt in more specifiers.
• resolve.alias handles polyfills and forwarding, since aliases resolve before the plugin.

node: stays opt-in rather than hardcoding the current shim list, because the set grows with each runtime version. Both READMEs show how to forward to the runtime's shims, using worker_threads as the example.

Vite coverage:

• vite build: the plugin runs first in the main build, worker builds and the dependency optimizer.
• HMR:
  • an esbuild counterpart runs first in the deps, vendor and core bundles;
  • /@id/<builtin> is unwrapped before the device rewriting passes;
  • guards in core rewriteSpec, worker-realm module bindings and the plugin-specifier check keep these imports untouched;
  • opted-in node: names are left out of the dev import map;
  • the CommonJS require shim tries the runtime's require first for ns: / node: ids.

Tests:

• packages/webpack5/__tests__/plugins/NativeScriptBuiltinModulesPlugin.spec.ts: real webpack compiles checking ESM and CommonJS output, polyfill and forwarding through NormalModuleReplacementPlugin, and the build failure without the plugin.
• packages/vite/helpers/builtin-modules.spec.ts: in-process vite build (ESM, import(), require() in a CommonJS dependency, alias forwarding and polyfill, and the failure without the plugin), plus the esbuild plugin.
• packages/vite/hmr/server/builtin-modules-hmr.spec.ts: each HMR touch point. All four tests fail without the HMR changes.

Notes for reviewers:

• The webpack config snapshots already fail on main: they contain absolute paths from another machine and a FixSourceMapUrlPlugin that no longer exists. I added only the new plugin entry to them rather than regenerating. The set of failing tests is identical to main. The mdn-data alias re-wrap in base.ts comes from the prettier pre-commit hook.
• packages/vite/typescript-optional.spec.ts also fails on main (5 tests) and is unchanged by this PR.
• Under HMR, the esbuild dependency bundles don't see Vite's resolve.alias. A ns: polyfill or bare-name forward set up with an alias applies to vite build and the Vite module graph, but not to dependencies bundled by esbuild during a dev session.
• No on-device run yet. Manual check: import ns:util from app code, a CommonJS dependency and a worker. Opt in node:worker_threads and check that it reaches the runtime, under both ns run (HMR) and a release build.