Add ".js" extension to injected polyfill imports

[shimataro]

Q	A
Fixed Issues?	Fixes #10548, fixes #8462
Patch: Bug Fix?	Yes
Major: Breaking Change?	No
Minor: New Feature?	No
Tests Added + Pass?	No
Documentation PR Link
Any Dependency Changes?	No
License	MIT

input:

for (const x of [1, 2, 3]) {
  console.log(x);
}

output(before):

import "core-js/modules/es.array.iterator";

for (const x of [1, 2, 3]) {
  console.log(x);
}

output(after):

import "core-js/modules/es.array.iterator.js"; // <- extension added!

for (const x of [1, 2, 3]) {
  console.log(x);
}

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.

[hg-pyun]

Is it mandatory?

[shimataro]

@hg-pyun
Thank you for your comment.

Is it mandatory?

Yes, it seems there are no reason that omitting extensions is better.

But, considering compatibility, is it better to add flag (for example, polyfillExtension) in .babelrc?

[nicolo-ribaudo]

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.
https://twitter.com/jasnell/status/1184265267951493120?s=20

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 @babel/plugin-transform-runtime.

[shimataro]

@nicolo-ribaudo
Thank you for your comment.

Note that it also needs to be updated in @babel/plugin-transform-runtime.

OK, I will do it later.

[buildsize]

File name	Previous Size	New Size	Change
babel-preset-env.js	2.73 MB	2.73 MB	20 bytes (0%)
babel-preset-env.min.js	1.65 MB	1.65 MB	18 bytes (0%)
babel.js	2.92 MB	2.92 MB	75 bytes (0%)
babel.min.js	1.61 MB	1.61 MB	63 bytes (0%)
test262.tap	4.84 MB	[deleted]

[shimataro]

@nicolo-ribaudo @hg-pyun
I also updated @babel/plugin-transform-runtime. Could you please review?

Note:

1. Many files are changed, but source files are only 2. The rest are test case.
   • packages/babel-preset-env/src/utils.js
   • packages/babel-plugin-transform-runtime/src/index.js
2. Since @babel/runtime/regenerator is a directory, import "@babel/runtime/regenerator" transforms into import "@babel/runtime/regenerator/index.js".

[nicolo-ribaudo]

@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

git fetch
git reset origin/add-js-extension-to-polyfill --hard

[nicolo-ribaudo]

Apart from a minor comment, this looks good 👍

[nicolo-ribaudo]

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.

[shimataro]

@nicolo-ribaudo
Is it fine c3b1bf5?

[JLHwung]

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.

[nicolo-ribaudo]

I don't think that it is a problem: in browsers those imports/requires don't work.
This code is targeting either node (for which a few more bites are way less important), or module bundles (which replace the import specifier with an id).

[jaydenseric]

Very keen for this; it's blocking me being able to support native ESM in a few packages.

[JLHwung]

Landed in v7.7.5.

[rwjblue]

FWIW, this has definitely broken users in the Ember ecosystem (using ember-cli-babel). There are many different bundling systems, and they do not all require that you include the file extension in the final module path. In fact, if you compile these @babel/runtime modules with Babel itself (via @babel/plugin-transform-modules-amd) the extension is not included in the defined module.

[JLHwung]

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)

[shimataro]

Really sorry, I messed up...

[nicolo-ribaudo]

@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)?

[shimataro]

@nicolo-ribaudo
I'm back, sorry too late.
I saw #10833 (comment), #10853 and #10862.

Is it resolved by #10853 and #10862, and no longer needed removeImportsExtension?