New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ".js" extension to injected polyfill imports #10549
Add ".js" extension to injected polyfill imports #10549
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it mandatory?
@hg-pyun
Yes, it seems there are no reason that omitting extensions is better. But, considering compatibility, is it better to add flag (for example, |
Node 13.0.0 will be released on October 22nd, and a copule of weeks later node 13.1.0 with unflagged modules support will be released. Given that there isn't a single reason for preferring it without the extension, I don't see why it should be introduced behind a flag. Note that it also needs to be updated in |
@nicolo-ribaudo
OK, I will do it later. |
@nicolo-ribaudo @hg-pyun Note:
|
50100e6
to
245676b
Compare
@shimataro I have reordered your commits to make it easier to review them. The first commit only contains the code changes, while the second one only the changes in the tests. If you need to update your local branch, you should run
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from a minor comment, this looks good
@@ -254,7 +254,7 @@ export default declare((api, options, dirname) => { | |||
if (cached) { | |||
cached = t.cloneNode(cached); | |||
} else { | |||
cached = addDefault(file.path, source, { | |||
cached = addDefault(file.path, `${source}.js`, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I would prefer not to add the extension here and to add it where addDefaultImport
, so that we are explicit about the files we are importing with assDefaultImport
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nicolo-ribaudo
Is it fine c3b1bf5?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a little bit concerned about the output size increase for CommonJS program source (sourceType === "script"
) -- every injected runtime helper now costs 3 bytes more.
While import
requires extension to be explicitly specified, could we only add *.js
extension only when
path.find(p => p.isProgram()).node.sourceType === "module"
so that CommonJS source does not have to add extra .js
.
Practically I don't think both babel runtime helpers and third party polyfill will have both foo
and foo.js
together, which is definitely a breaking change, so it is safely to remove *.js
for CommonJS source type.
I don't think that it is a problem: in browsers those imports/requires don't work. |
Very keen for this; it's blocking me being able to support native ESM in a few packages. |
Note that the injected Babel helper imports still require file extensions to work in Node.js, see: babel/babel#10549 (comment)
0ba6bfa
to
fdf5c74
Compare
Landed in v7.7.5. |
FWIW, this has definitely broken users in the Ember ecosystem (using |
This reverts commit d3a37b5.
Updates: this PR will be reverted in 7.7.6. We will bring back the behaviour under a configurable option in 7.8.0. C.f. #10833 (comment) |
Really sorry, I messed up... |
@shimataro It's not a problem! We should have been more careful when reviewing the PR Would you like to reopen this PR, behind an option, as described in #10833 (comment)? |
@nicolo-ribaudo Is it resolved by #10853 and #10862, and no longer needed |
input:
output(before):
output(after):
As of Node.js v12,
import
syntax requires extension.https://medium.com/@nodejs/announcing-a-new-experimental-modules-1be8d2d6c2ff
Please refer #10548 for more details.