vite dev: semi-framework crawl pre-bundles a library's node-only dependencies (@yak/solid > @swc/core) since next.44
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 76/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- node.js, typescript, vite
- 領域
- build-system, tooling
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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
- 主要言語
- TypeScript
- スター
- 520
- フォーク
- 70
- 平均マージ
- 16時間 4分
- マージ済み PR（30日）
- 34
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
solidjs/solid-vite-plugin のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
solidjs/solid-vite-plugin#205 · コメント 1 件 · リアクション 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
solidjs/solid-vite-plugin#369 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
solidjs/solid-vite-plugin#328 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
solidjs/solid-vite-plugin#308 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
solidjs/solid-vite-plugin#262 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
solidjs/solid-vite-plugin の issue をすべて見る
似ている issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
supabase/agent-skills#611 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 68/100
polka-codes/test#345 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 92/100
GoogleChromeLabs/project-sesame#217 ·
メンテナーはふだん 12 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
solana-foundation/solana-com#2202 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100