Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Geschlossen
  • Stimmt etwas nicht?
#375 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
node.js, typescript, vite
Bereich
build-system, tooling

Rechercherichtung

Start with isSemiFrameworkPkgByJson, crawlFrameworkPkgs, pkgNeedsOptimization, and solidPkgsConfig.optimizeDeps.include to trace how semi-framework dependencies enter the optimizer. Apply the proposed post-crawl filtering for recorded semi-framework packages, then run the next-yak e2e/bundlers/vite-solid suite under vite dev, including its client, SSR, and HMR cases. Done means the suite passes and @swc/core's native binding is no longer pre-bundled.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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/@[email protected]/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

Vorherrschende Sprache
TypeScript
Sterne
522
Forks
72
Ø Merge
1 T. 3 Std.
Gemergte PRs (30 T.)
38

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus solidjs/solid-vite-plugin

Alle Issues in solidjs/solid-vite-plugin

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.