fix(vite): serve a symlinked nativescript-vue as library code in HMR - #11430
Merged
NathanWalker merged 1 commit intoSep 14, 2026
Merged
Conversation
A served package request was classified from its resolved id alone. A symlinked package (file: or npm link) resolves to a real path without a node_modules segment, so it was treated as app source and received the app-only passes, including an injected import of the /ns/rt bridge. The bridge then evaluated before nativescript-vue was registered, cached an empty object and left every binding undefined. Classify from the request spec as well, and stop caching a registry miss in __ensure() so a later lookup can succeed; warn once instead of failing later with "X is not a function". Fixes NativeScript#11429
|
View your CI Pipeline Execution ↗ for commit f7aa964
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
5 tasks
commit: |
NathanWalker
approved these changes
Sep 14, 2026
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
2 participants
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.
PR Checklist
What is the current behavior?
With
nativescript-vueinstalled as a symlink (file:../pathornpm link),ns debug iosfails at boot with_defineComponent is not a function.websocket-ns-m.tsclassified the served/ns/m/node_modules/nativescript-vuerequest fromresolvedCandidate || spec; the resolved candidate of a symlinked package is its real path, which has nonode_modules/segment, so the module counted as app source andprocessCodeForDeviceran the app-only passes on it, injectingimport { $navigateTo, $navigateBack } from "/ns/rt". The bridge then evaluated as a dependency ofnativescript-vue, before the vendor registry had the package, and__ensure()cached{}for the rest of the session.What is the new behavior?
classifyServedRequest(spec, resolvedId)classifies a request as library code when either the spec or the resolved id is undernode_modules/(or a workspace core/vite path).websocket-ns-m.tsuses it for theisNodeModgate.__ensure()in the/ns/rtbridge no longer caches a miss, so a later call sees the registration, and warns once ([ns-rt] nativescript-vue is not registered in the vendor registry yet…) so the failure is diagnosable.Verified against the repro in nativescript-vue/nativescript-vue#1160: with a real directory the served module is clean; with the symlink the served module carried the bridge import.
Fixes #11429 (part 2; the rolldown alias problem in part 1 is a separate PR).
npx vitest runinpackages/vite: the only failures are the pre-existingtypescript-optional.spec.tscases, which need a built package.