Panic message

thread 'rolldown-worker' panicked at crates\rolldown\src\stages\generate_stage\compute_cross_chunk_links.rs:584:13:
Symbol "common_functions" in ".../node_modules/three-mesh-bvh/src/webgl/glsl/common_functions.glsl.js" should belong to a chunk
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Reproduction

https://github.com/marwie/rolldown-panick-regression-1.1.5

• npm install
• npx [email protected] -c rolldown.config.mjs # → panic

or, through Vite:

• npm run build # → same panic

System Info

- Rolldown: 1.1.5 and 1.2.0 (CLI); also via Vite 8.1.5
- OS: Windows 11 Pro (10.0.26200), x64
- Node: v24.14.0
- Package manager: npm

Additional context

• Removing the codeSplitting group makes the build pass. Using manualChunks with the same module→chunk mapping also passes.
• The panicking symbol is reached through a namespace re-export chain in a "sideEffects": false package:
  • three-mesh-bvh/src/index.js: export * as BVHShaderGLSL from './webgl/BVHShaderGLSL.js' — plus import * as BVHShaderGLSL and a top-level `${BVHShaderGLSL.common_functions}` usage.
  • src/webgl/BVHShaderGLSL.js: export * from './glsl/common_functions.glsl.js'.
• The entry must reach the package via dynamic import() (a static import does not panic in our tests).
• includeDependenciesRecursively: false on the group does not help.
• Changing the group test so the glsl modules are NOT matched does not help either — grouping any part of the package (or even only grouping the importer of the package, leaving three-mesh-bvh itself ungrouped) still panics with the same symbol.

Given the 1.1.4 → 1.1.5 window, possibly related changes: #10111 ("skip side-effect-free modules in per-entry reachability") or #10087 ("make module namespace inclusion an explicit linking metadata field").