Skip to content

Version Packages (next) #355

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ryansolid merged 1 commit into from
Sep 10, 2026
+10 −1
Merged

Version Packages (next) #355

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .changeset/pre.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,7 @@
"lazy-load-native-compiler",
"lazy-manifest-robustness",
"license-and-manifest-docs",
"manifest-client-entry-identity",
"native-babel-free-refresh",
"native-compiler-custom-extensions",
"native-compiler-option",
Expand Down Expand Up @@ -91,6 +92,7 @@
"server-functions-turnkey",
"six-lions-joke",
"solid-compiler-packages",
"ssr-inline-solid-consumers",
"start-css-filter",
"start-env-typed",
"start-mode-terminology",
Expand Down
7 changes: 7 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,12 @@
# Changelog

## 3.0.0-next.41

### Patch Changes

- 38434e1: Fix the start-mode handler booting the wrong chunk when the client build has several configured inputs (#353, a regression of 3.0.0-next.40 / #347). With filesystem-routing's `fileRoutes({ routers: { client }, buildInputs: 'client' })` every route module is a `build.rollupOptions.input`, and since #347 those records rightly keep `isEntry` in `virtual:solid-manifest`. The generated handler resolved the client entry by scanning for the first `isEntry` record, so a route key sorting ahead of the plugin's own `virtual:solid-ssr-entry-client.tsx` won: the document's `<script type="module">` pointed at the route chunk (the page never hydrated) and `<head>` linked that route's CSS while the entry graph's global stylesheet was never linked. The manifest module now names the client entry explicitly — `_entry` carries its key (the entry start mode injects, or the single configured input outside start mode) and its record is serialized first — and the handler reads `_entry` before falling back to the `isEntry` scan for hand-rolled manifests. `@solidjs/web`'s `registerEntryAssets`, which links the entry graph's stylesheets and modulepreloads by the first `isEntry` record, therefore agrees on the same chunk. Other configured inputs keep `isEntry`; they are genuine entries, just not the one the document boots.
- bd04c66: Packages that consume the Solid runtime without declaring a `solid` export condition are now inlined in dev server environments too, closing the remaining half of the two-instance split. Inlining `solid-js` and `@solidjs/web` fixes every resolution those two perform, and vitefu inlines packages that advertise a `solid` export condition — but a package that does neither is still externalized, and Node resolves its own `import "solid-js"` without the `development` condition, so it loads the production server build while the inlined graph holds the dev one. `@solidjs/meta` is the first-party example: it has no `solid` condition, so under solid-js 2.0.0-rc.7 an app rendering a `<Title>` still died in `useContext` on a second `sharedConfig` even with the core packages inlined. The crawl now also classifies any package declaring `solid-js` or `@solidjs/web` in its `dependencies` or `peerDependencies` as a semi-framework package — `ssr.noExternal` without `optimizeDeps.exclude`, since these hold no raw Solid components — so third-party component libraries and metadata helpers reach the same copy as everything else. Gated on the dev-condition swap (and off under vitest, which manages inlining itself), leaving builds unchanged. Two guards keep the rule narrow: tooling that declares `solid-js` as a peer but never runs inside the SSR module runner — `@solidjs/vite-plugin` itself, `vite`, `vitest`, `eslint-plugin-*`, `vite-plugin-*`, `prettier-plugin-*`, `@types/*` — is skipped entirely (classifying the plugin would also crawl its dependencies and pre-bundle `@babel/core` and `@solidjs/babel-plugin` into the browser's `optimizeDeps`, several megabytes of dead weight per cold start); and the `ssr.external` list vitefu derives from framework packages' non-framework `dependencies` is filtered against the final `noExternal` list, because Vite gives `external` precedence — a framework package listing `@solidjs/web` under `dependencies` (e.g. `@tanstack/solid-router`) would otherwise re-externalize a core the plugin just inlined and split the runtime again.

## 3.0.0-next.40

### Minor Changes
Expand Down
2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "@solidjs/vite-plugin",
"version": "3.0.0-next.40",
"version": "3.0.0-next.41",
"description": "solid-js integration plugin for Vite",
"type": "module",
"engines": {
Expand Down