Use entryFileNames when generating filenames for virtual modules #4270
+234
−55
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BPScott
changed the title
Codecov Report
@@ Coverage Diff @@
## master #4270 +/- ##
=======================================
Coverage 98.39% 98.40%
=======================================
Files 204 204
Lines 7312 7319 +7
Branches 2084 2084
=======================================
+ Hits 7195 7202 +7
Misses 58 58
Partials 59 59
Continue to review full report at Codecov.
|
BPScott
force-pushed
the
virtual-module-entryfilenames
branch
from
61e0d7d to
a49072f
Compare
- virtual files now have a .js extension by default - systemjs module references include this file extension - amd module references omit this file extension. this seems to be consistent with amd output of other chunks
Use entryFileNames to change the extension of the filename to be mjs, and see that the file created from the virtual file chunk has a .mjs extension Note that the amd definition contains the .mjs extension, as amd ids only strip the .js file extension, which is slightly odd but probably ok as this amd is not the targetted usecase for this behaviour
BPScott
force-pushed
the
virtual-module-entryfilenames
branch
from
a49072f to
8f3747b
Compare
|
Rebased atop latest master |
|
Thank you @lukastaegert <3 |
This was referenced Dec 9, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Resolves #4269
Resolves rollup/plugins#1031
Resolves rollup/plugins#1037
Description
When
output.preserveModules:trueis set and there are virtual modules, rollup creates files on disk for each of those virtual modules.Prior to this PR the filename was the sanitised virtual module id but no further transformation was done. This meant that if the virtual module id had no extension, then the filename on disk lacked an extension, and if did specify an extension then the filename on disk would always be that extension, even if
output. entryFileNamestried to use a different filename.This causes issues in cases where an environment can not load files that lack an extension (such as web browsers when the server can't set the correct mime-type - rollup/plugins#1037) or when the extension needs to be changed (such as when you want to create
.mjsfiles for node esm support - rollup/plugins#1031)With this PR, the filenames of virtual modules are processed with
output.entryFileNamesin the same way as non-virtual modules - which by default will add a.jsextension to generated files and shall allow for customization of the extension of the filename.Notes
This PR has been split into three commits to try and help ease reviewing
\0virtualModulepreviously generated_virtual/_virtualModuleand now generates_virtual/_virtualModule.js\0other.js?commonjs-exports.jspreviously generated_virtual/_other.js_commonjs-exportsand now generates_virtual/other.js_commonjs-exports.js.jsextension, this seems to be consistent with how files produced from non-virtual modules are referenced.jsextension, but include other extensions, this seems to be consistent with how files produced from non-virtual modules are referenced