You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally raised in rollup/plugins#1031, but I think the issue might be better solved at the rollup-level rather than the plugin-level.
When output.preserveModules:true is set and there are virtual files, rollup should use output.entryFileNames to generate the filename of created virtual files.
When given the following output options, virtual files should be output with a .mjs extension, regardless of their original file extension:
I.e. in the given example that uses plugin-babel - ./_virtual/_rollupPluginBabelHelpers.js should be named ./_virtual/_rollupPluginBabelHelpers.mjs.
Actual Behaviour
When output.preserveModules:true and output.entryFilenames is set and there are virtual files, rollup does not use entryFileNames to generate the filename of created virtual files.
In the above demo the _rollupPluginBabelHelpers virtual file is output with the filename ./_virtual/_rollupPluginBabelHelpers.js.
This then breaks running compiled output in node as node assumes that contents of ./_virtual/_rollupPluginBabelHelpers.js is commonjs, but it is actually esm.
Bonus thoughts
I believe the fix for this lives within Chunk.ts's generateIdPreserveModules. I've tried moving the definition of fileName above the isAbsolute() if block, and changing setting the virtual path block to be "path = _virtual/${fileName};". This seems to give me the filename I'm after, but I get lots of test failures that I can't seem to resolve by updating expected sample output, so clearly I'm missing a trick somewhere.
The text was updated successfully, but these errors were encountered:
It looks like fixing this would also solve rollup/plugins#1037 which relates to virtual files getting any file extension before.
In the past there has been a few bugfixes at the plugin level where plugins had to add a .js extension to virtual files - rollup/rollup-plugin-commonjs#373 and rollup/rollup-plugin-babel#296, which probably could also have been avoided by this proposed fix at the rollup level.
Doing the below in the else block in generateIdPreserveModules seems to be looking promising.
Hopefully I'll be able to raise a PR in the next few days.
Rollup Version
2.59.0
Operating System (or Browser)
macos
Node Version (if applicable)
Not relevant to rollup output. But a version with support for
.mjs
files is needed to showcase the bugLink To Reproduction
https://replit.com/@BPScott/rollup-plugin-babel-repl-helpers-bad-filename
Expected Behaviour
Originally raised in rollup/plugins#1031, but I think the issue might be better solved at the rollup-level rather than the plugin-level.
When
output.preserveModules:true
is set and there are virtual files, rollup should useoutput.entryFileNames
to generate the filename of created virtual files.When given the following output options, virtual files should be output with a
.mjs
extension, regardless of their original file extension:I.e. in the given example that uses plugin-babel -
./_virtual/_rollupPluginBabelHelpers.js
should be named./_virtual/_rollupPluginBabelHelpers.mjs
.Actual Behaviour
When
output.preserveModules:true
andoutput.entryFilenames
is set and there are virtual files, rollup does not useentryFileNames
to generate the filename of created virtual files.In the above demo the
_rollupPluginBabelHelpers
virtual file is output with the filename./_virtual/_rollupPluginBabelHelpers.js
.This then breaks running compiled output in node as node assumes that contents of
./_virtual/_rollupPluginBabelHelpers.js
is commonjs, but it is actually esm.Bonus thoughts
I believe the fix for this lives within Chunk.ts's
generateIdPreserveModules
. I've tried moving the definition offileName
above theisAbsolute()
if block, and changing setting the virtual path block to be "path =_virtual/${fileName}
;". This seems to give me the filename I'm after, but I get lots of test failures that I can't seem to resolve by updating expected sample output, so clearly I'm missing a trick somewhere.The text was updated successfully, but these errors were encountered: