Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#375 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript, vite
Lĩnh vực
build-system, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
TypeScript
Star
520
Fork
70
Merge trung bình
14 giờ 54 phút
Pull request đã merge (30 ngày)
32

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid-vite-plugin

Tất cả issue của solidjs/solid-vite-plugin

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.