Do not add .js extension to injected helper imports when module transform presents

[JLHwung]

Q	A
Fixed Issues?	Fixes #10832
Patch: Bug Fix?	Yes
Tests Added + Pass?	Yes
License	MIT

As a follow up to #10549, this PR partially reverts the recently introduced behaviour on the helper imports. It will remove .js added in #10549 when other module transforms presents.

The .js extension is only required by native ES Modules and we can safely remove it when it will be transformed to other module formats.

Compatibility Note:

When using transform-runtime 7.7.6 with

• modules-umd < 7.7.6
• modules-amd < 7.5.0

it will still add the .js extension to imports due to lack of context variables. This will cause trouble to AMD users. If you are experience this issue, please upgrade these plugins to 7.7.6.

[JLHwung]

Technically only amd and umd are affected by this issue since by default RequireJS does not support resolving foo.js => foo.js as-is out of the box. You may configure to support this but we did cause breaking changes to these users.

Both CommonJS and SystemJS support foo.js => foo.js, but at the same time they also support foo => foo.js. Hence I remove .js for the sake of briefness. C.f. #10549 (review)

[JLHwung]

I rewrite this test case since it looks more practical that an ESM supported environment does not support class-properties and so we need to transform.

[LarsDenBakker]

This should not apply to systemjs transform, or be configurable. Systemjs is an es module compliant polyfill. We use this in https://www.npmjs.com/package/es-dev-server where we use es modules in the browser during development and fallback to systemjs if modules are not supported.

[nicolo-ribaudo]

@babel/core-team What do you think about reverting the PR which introduced the regression, releasing it before Monday and then re-introducing the .js suffix behind an option?

Systemjs is an es module compliant polyfill.

Note that the es modules specification doesn't say anything about file extension. The .js extension is never mentioned in the ECMAScript standard, and I think that it isn't mentioned by all the web platform stands neither (or at least, if it's meaningless).

[chriskrycho]

The .js extension is never mentioned in the ECMAScript standard, and I think that it isn't mentioned by all the web platform stands neither (or at least, if it's meaningless).

Indeed! More, the spec is intentionally silent on how a string is to be resolved. A given module loader (browser, Node, etc.) may choose to implement its own rules for the string parse. It is required to be a string literal, but that is the only thing specified about the module specifier.

[JLHwung]

@LarsDenBakker This PR restores to behaviour for SystemJS to pre 7.7.5 so it should work.

I discussed with @nicolo-ribaudo a bit and we are now reverting #10549 for 7.7.6. This PR is thus closed.

A new option removeImportsExtension: boolean will be introduced in 7.8.0. It defaults to true so the behaviour will be aligned to pre-7.7.5, which means we still generate @babel/runtime/foo imports. For those people publishing the es modules, they will have to set it false.

We are planing to change its default to false on 8.x, which is more meaningful to current ES Modules implementation while still providing backward supports to other module standards, i.e. amd.

[LarsDenBakker]

Makes sense guys, thanks!