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#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

Under HMR, deps-bundle discovery only follows static imports. Dynamic import() targets inside dependency code are externalized to their /ns/m/node_modules/... URL, and unless something else imports them statically, neither they nor anything they import end up in the bundle.

When a dependency lazily loads part of itself after boot (for example, when a screen is first opened), the device fetches that closure one module at a time. The dev server also transforms each of those modules on first request. In one app this blocked the JS thread for 3.8 s the first time a screen opened (~510 ms once the server's transforms were warm). The same screen opens in ~80 ms without HMR.

What is the new behavior?

• The import-routing plugin reports every node_modules import() target it externalizes.
• After the main discovery pass, those targets and their closures are discovered too (repeating until no new targets turn up), and every file found is registered lazily like any other discovered input.
• The import() call itself is unchanged: it still goes to the canonical /ns/m URL. That URL now serves a shim into the bundle, so evaluation stays lazy and module identity is preserved.
• This is best effort. A target whose closure fails to build (tried as a batch, then one by one) keeps per-module serving and does not fail the bundle. Probe builds run without metafile, the same guard against esbuild 0.27 throwing outside the build promise that is used elsewhere.

In the app above, the first visit now takes 116 ms with a fresh dev server. Building the bundle took 9.4 s instead of 7.9 s.

Tests: deps-bundle.spec.ts covers a chained import() (target, its static import, and its own dynamic import are all registered), and a target with an unresolvable closure that stays per-module next to one that bundles. Two createDepsBundleService tests (opaque CJS / react-like shims) fail on main without this change too, on Windows.