vite dev: semi-framework crawl pre-bundles a library's node-only dependencies (@yak/solid > @swc/core) since next.44 #375

Since 3.0.0-next.44 (ssr-inline-solid-consumers), vite dev fails in dependency optimization for an app using @yak/solid (DigitecGalaxus/next-yak):

Error: Error during dependency optimization:
[UNLOADABLE_DEPENDENCY] Could not load ../../node_modules/.pnpm/@swc+core-darwin-arm64@1.15.47/node_modules/@swc/core-darwin-arm64/swc.darwin-arm64.node
     ╭─[ …/@swc/core/binding.js:159:24 ]
 159 │         return require('@swc/core-darwin-arm64')
     │                        ────────────┬───────────
     │                                    ╰───────────── stream did not contain valid UTF-8

Reproduced with next.44 and with next at 08782f2 (what next.45 ships); next.38 is fine. The app is next-yak's e2e/bundlers/vite-solid (client + SSR, plugins: [yak(), solid({ ssr: true })]); vite build is unaffected, only vite dev.

Cause

The new semi-framework classification marks any package with solid-js / @solidjs/web in dependencies or peerDependencies as semi-framework so it is ssr.noExternal (one runtime copy). That is the right call for the package itself, but vitefu's crawl treats a semi-framework package like a framework package for its dependencies too: every CJS dependency of it is pushed into optimizeDeps.include as "<pkg> > <dep>" (crawlFrameworkPkgs → pkgNeedsOptimization).

@yak/solid declares solid-js as a peer (semi-framework) and, because its Vite plugin ships in the same package (@yak/solid/vite), lists @swc/core, @babel/parser and yak-swc under dependencies. So @yak/solid > @swc/core lands in the browser optimizer's include list, and rolldown tries to bundle a native .node binding.

Any Solid library that ships a build-time half in the same package (a Vite/Babel plugin, a CLI, a server adapter with node-only deps) hits this the moment it is on next.44+ under vite dev. A framework package (one with a solid export condition) has always had this behaviour from vitefu, but the semi-framework rule extends it to every peer-dependent library, which is a much wider net.

Suggested fix

A semi-framework package is inlined so it shares the runtime; nothing about that needs its own dependencies pre-bundled. Record the semi-framework package names in isSemiFrameworkPkgByJson and drop their entries from solidPkgsConfig.optimizeDeps.include:

const semiFrameworkPkgs = new Set<string>();
// …
isSemiFrameworkPkgByJson(pkgJson) {
  if (!(replaceDev || observe) || isTestMode) return false;
  const semi = SOLID_RUNTIME_PKGS.some(
    (name) => pkgJson.dependencies?.[name] || pkgJson.peerDependencies?.[name],
  );
  if (semi && pkgJson.name) semiFrameworkPkgs.add(pkgJson.name);
  return semi;
},
// …after crawlFrameworkPkgs:
solidPkgsConfig.optimizeDeps.include = solidPkgsConfig.optimizeDeps.include.filter(
  (entry) => !semiFrameworkPkgs.has(entry.split(' > ')[0]),
);

With that patch applied to next (built locally), next-yak's full vite-solid e2e passes under vite dev with Solid 2.0.0-rc.10 (36 cases + 7 HMR cases, both fold modes). A browser-side CJS dep of such a package would then be discovered and optimized on first use by Vite instead of up front — a reload in dev at worst, against a hard failure today.

The alternative — not crawling semi-framework packages' deps at all — is not something vitefu's crawlFrameworkPkgs options offer (isSemiFrameworkPkgByJson always recurses), so the post-filter is the smallest change.

Context

Found while preparing DigitecGalaxus/next-yak's move to solid-js 2.0.0-rc.10 (DigitecGalaxus/next-yak#658 and its follow-up). That PR keeps @solidjs/vite-plugin pinned at 3.0.0-next.38 because of this; next.45 also fixes the componentNames → sourceNames option rename the rc.10 compiler needs, so once this lands they can move to one release that works.

— Claude via Cursor