Skip to content

fix: inline packages that consume the Solid runtime in dev - #352

Open
brenelz wants to merge 1 commit into
solidjs:nextfrom
brenelz:fix/ssr-inline-solid-consumers
Open

fix: inline packages that consume the Solid runtime in dev#352
brenelz wants to merge 1 commit into
solidjs:nextfrom
brenelz:fix/ssr-inline-solid-consumers

Conversation

@brenelz

@brenelz brenelz commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

Follow-up to a810d09 (#350), rebased onto it. That commit fixes the split for
solid-js and @solidjs/web; this closes the remaining half.

The gap

a810d09 reasons:

Framework packages that declare the solid export condition are already
inlined via vitefu below and reach the same copy.

@solidjs/meta declares no solid export condition:

@solidjs/router  exports contains "solid": true   -> inlined by vitefu
@solidjs/meta    exports contains "solid": false  -> still externalized
solid-js         false  -> now inlined by a810d09
@solidjs/web     false  -> now inlined by a810d09

So it stays external, Node resolves its own import "solid-js" without the
development condition, and it loads the production server build while the
inlined graph holds the dev one — the same two sharedConfigs, one layer out.
On 3.0.0-next.40 an app that renders a <Title> still dies:

at getContext (solid-js/dist/server.js:104)      <- production build
at useContext (solid-js/dist/server.js:1476)
at headTag    (@solidjs/meta/dist/index.js:36)
at Title      (@solidjs/meta/dist/index.js:79)

It generalises past first-party packages: any component library or helper that
imports solid-js without advertising a solid condition splits the runtime
the same way.

The change

vitefu's semi-framework class is the right bucket — ssr.noExternal without
optimizeDeps.exclude, since these carry no raw Solid components:

isSemiFrameworkPkgByJson(pkgJson) {
  if (!replaceDev) return false;
  return SOLID_RUNTIME_PKGS.some(
    (name) => pkgJson.dependencies?.[name] || pkgJson.peerDependencies?.[name],
  );
},

Gated on replaceDev, so builds are unchanged. It composes with a810d09 rather
than replacing it: that commit still covers the two core packages directly,
including the case where a consumer is absent.

Verified

A start-mode app (start + ssr: true, file routes, server functions,
@solidjs/meta) on solid-js / @solidjs/web 2.0.0-rc.7, @solidjs/router
2.0.0-next.21, Vite 8.2.2:

plugin vite dev
3.0.0-next.39 500 — lazy() … no asset manifest is set
3.0.0-next.40 (a810d09) 500 — useContext in @solidjs/meta, prod build
next.40 + noExternal: ['@solidjs/meta'] by hand 200
this branch 200

vite build + vite preview stayed 200 throughout — a build applies no
development condition, so nothing splits there. Tested with this branch's
built dist/esm/index.mjs dropped into that app with no ssr.noExternal in its
own config. pnpm build (rollup + tsc --emitDeclarationOnly) is clean.

No regression test added — the suites run examples end to end and I could not
tell where a two-instance assertion belongs. examples/ssr and
examples/css-matrix would only catch this with a @solidjs/meta dependency in
the fixture; happy to add that if it is the right shape.

@changeset-bot

changeset-bot Bot commented Sep 8, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 02207d9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@solidjs/vite-plugin Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@pkg-pr-new

pkg-pr-new Bot commented Sep 8, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@352

commit: 02207d9

Follow-up to a810d09. Inlining solid-js and @solidjs/web fixes every
resolution those two perform, and vitefu inlines packages advertising a
`solid` export condition. A package that does neither is still external,
so Node resolves its own `import "solid-js"` without `development` and
loads the production server build while the inlined graph holds the dev
one — the same two-instance split, one layer out.

@solidjs/meta is the first-party case: no `solid` export condition, so an
app rendering <Title> still fails in useContext under solid-js
2.0.0-rc.7 with the core packages already inlined.

Classify any package declaring solid-js or @solidjs/web in dependencies
or peerDependencies as a semi-framework package: ssr.noExternal without
optimizeDeps.exclude, which is right here as they carry no raw Solid
components. Gated on replaceDev, so builds are unchanged.
@brenelz
brenelz force-pushed the fix/ssr-inline-solid-consumers branch from bdf2b24 to 02207d9 Compare September 8, 2026 18:11
@brenelz brenelz changed the title fix: inline solid-js consumers in the SSR dev graph fix: inline packages that consume the Solid runtime in dev Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant