Repository navigation
Class constructor readonly arguments generate heavily nested runtime files #265
Description
Reproduction link or steps
https://github.com/tats-u/tsdown-prop-bug
- Clone
pnpm inode --run build- Check the generated files
What is expected?
Only index.{d.ts,js} exist
build:tsup instead of build can get this result
What is actually happening?
Other extra files exist.
They contain abnormally nested references like:
import { __commonJS } from "../../../../../../../../_virtual/rolldown_runtime.js";Any additional comments?
tsup don't generate such extra files.
Activity
Gugustinette commentedon May 26, 2025
This is caused by the unbundle mode, turning it off will generate only
index.jsandindex.d.tsas you expect.sxzz commentedon May 27, 2025
_virtual: Since unbundle mode is enabled, the rolldown runtime will be extracted into a separate file. This is the expected behavior. In contrast, esbuild and tsup duplicate the runtime code in every single file.node_modules: track Partial bundling #262tats-u commentedon May 27, 2025
JS files in
dist\node_modules\.pnpm\@oxc-project_runtime@0.71.0\node_modules\@oxc-project\runtime\src\helpershave following malformed import and require:[-]Class constructor readonly arguments generate extra runtime files[/-][+]Class constructor readonly arguments generate extra invalid runtime files[/+][-]Class constructor readonly arguments generate extra invalid runtime files[/-][+]Class constructor readonly arguments generate heavyly nested runtime files[/+][-]Class constructor readonly arguments generate heavyly nested runtime files[/-][+]Class constructor readonly arguments generate heavily nested runtime files[/+]Gugustinette commentedon Aug 4, 2025
@tats-u the import you pointed out seems fine to me ?
I mean it is ugly looking of course, but that's what it should be, it correctly points to the imported file. (Atleast it was the case when I built with the repo you gave)
tats-u commentedon Aug 5, 2025
What if you publish files including that funny import statement as an npm package and users install that package in a non-monorepo project and execute that statement? Node will try to read a js file in the _virtual directory in the file system root directory due to so many ../.
Gugustinette commentedon Aug 5, 2025
@tats-u As far as I tested it works, so you should provide a reproduction that clearly demonstrate this (for example configuring two npm packages locally, using the
file:../protocol).tats-u commentedon Sep 4, 2025
Probably my misunderstanding.
sxzz commentedon Oct 28, 2026
Closing since the reporter confirmed the deep
_virtualimport path works at runtime. Feel free to reopen with a reproduction if it actually breaks consumers.