GeezerVison is showing github.com — fix(vite): resolve Solid runtime dev builds from package exports by NathanWalker · Pull Request #11628 · NativeScript/NativeScript
Conversation
PR Checklist
What is the current behavior?
With solid-js / @solidjs/* 2.0.0-rc.19, an HMR dev session fails at boot:
[ns-entry] deterministic dev session bootstrap failed TypeError: Cannot read properties of undefined (reading 'guideUrl')
at installConsoleFooter (http://…/ns/m/node_modules/solid-js/dist/solid.dev.js:1725:26)
Two causes, both from Solid's rc.19 package layout:
@solidjs/signals resolves to its prod build. The deps bundle, its root-URL shims, and the bare-import rewrite all resolve packages without the development condition, so @solidjs/signals lands on dist/prod/index.js, where DEV is undefined. rc.19's solid.dev.js reads DEV.guideUrl at module load. (rc.0 also paired with prod signals, but nothing read DEV at load.)
solid-js/dist/dev.js no longer exists. The canonical solid-js URL is hard-coded in rewrite-imports, the deps bundle (seed + routing), the Solid strategy's import map, and configuration/solid.ts. rc.19 renamed the file to dist/solid.dev.js, so these URLs 404, and they diverge from the solid.dev.js URL other importers reach, which would load a second Solid instance.
What is the new behavior?
helpers/solid-runtime.ts resolves the dev build of each Solid runtime package root (solid-js, @solidjs/signals, @solidjs/universal, @solidjs/web) from that package's own exports map, preferring targets under development. All Solid pin sites use it:
rewrite-imports: bare runtime roots rewrite to /ns/m/node_modules/<pkg>/<dev entry>.
deps-bundle: the routing plugin, the vendor seed, recorded boot paths (an old recording containing /ns/m/node_modules/@solidjs/signals no longer bundles prod), and package-root URL → shim lookup all go through one resolveDepsSpecToFile.
- Solid strategy
importMapEntries: solid-js maps to the resolved dev URL.
configuration/solid.ts: in dev, aliases the runtime packages to their dev builds. Aliases are now anchored, so subpaths like solid-js/internal reach the exports map instead of being prefix-matched to …/dist/dev.js/internal.
Compatibility:
solid-js 1.x and 2.0.0-rc.0 still resolve to dist/dev.js. The exports maps of all three layouts are covered in solid-runtime.spec.ts.
- When the exports map names no dev build,
solid-js falls back to the legacy dist/dev.js.
- The
development condition is intentionally not enabled globally (see the conditions note in hmr/shared/vendor/manifest.ts about isServer stubs). Other flavors and non-Solid packages are unchanged.
Verified against an rc.19 app:
- The deps bundle registers only
solid.dev.js, signals/dist/dev.js, universal.dev.js and solid-js/dist/internal.js, with no prod Solid files.
/ns/m/node_modules/{solid-js,@solidjs/signals,@solidjs/universal} serve shims of those dev builds.
- The import map's
solid-js points at dist/solid.dev.js, and app modules import the same URL. This holds with and without app-level Solid aliases.
- The full
packages/vite suite passes (166 files / 1943 tests), and the new deps-bundle test fails on main.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Solid 2.0.0-rc.19 moved solid-js's dev build from dist/dev.js to
dist/solid.dev.js and made it read DEV from @solidjs/signals at module
load. The HMR pipeline hard-coded dist/dev.js (now a 404) and resolved
@solidjs/signals without the development condition, so solid.dev.js
paired with the signals prod build and threw reading DEV.guideUrl.
Resolve the dev entry of solid-js, @solidjs/signals, @solidjs/universal
and @solidjs/web from each package's exports map and pin bare imports,
recorded boot paths, package-root URLs, the import map and the dev
aliases to it. Solid 1.x and 2.0 rc.0 keep resolving to dist/dev.js;
other flavors and packages are untouched.
nx-cloud
Bot
commented
Nov 9, 2026
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
|
View your CI Pipeline Execution ↗ for commit 4b207d7
| Command |
Status |
Duration |
Result |
nx test apps-automated -c=android |
✅ Succeeded |
3m 13s |
View ↗ |
nx run-many --target=test --configuration=ci --... |
✅ Succeeded |
<1s |
View ↗ |
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗
☁️ Nx Cloud last updated this comment at 2026-11-09 22:21:32 UTC
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
Open in StackBlitz
npm i https://pkg.pr.new/@nativescript/core@11628
npm i https://pkg.pr.new/@nativescript/vite@11628
npm i https://pkg.pr.new/@nativescript/webpack@11628
commit: 4b207d7
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
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.
|