Add .mjs to the examples

[philipwalton]

As developers are starting to publish .mjs files to npm, people are starting to see breakage in unexpected ways (e.g. this tweet) due to the fact that most babel-loader users copy and paste the test: /\.js$/ line into their config.

While we can't update everyone's existing configs, we can update the canonical examples.

/cc @mathiasbynens @developit

Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Does this PR introduce a breaking change?

• Yes
• No

[loganfsmyth]

I admit, I'm very on the fence here because it seems like publishing .mjs currently is actively hostile in 99% of cases because there's no guarantee that .mjs files publishes now would be compatible with Node's eventual implementation. The only safe .mjs implementation right now would be one that has 0 external dependencies, or at least 0 external CommonJS deps. It seems like anything encouraging .mjs support should be shunned until Node settles on interop behavior.

[loganfsmyth]

I guess at the end of the day it's not really our call how people do this, but boy does it seem like a terrible idea at the moment.

[philipwalton]

I've never been crazy about the extension name myself, but since all modern browsers already do ship a module implementation that actually runs code differently from how it runs regular scripts, I think it's wise to recommend developers use a different extension in order to express the intent of where the code will be run.

My colleague @mathiasbynens wrote an article promoting .mjs (and he may have more thoughts here) so more people are starting to use this, and unfortunately many of them are hitting issues like this and getting confused.

I've added a note to one of my blogs posts around the potential gotchas of .mjs, so hopefully that will help as well: https://philipwalton.com/articles/deploying-es2015-code-in-production-today/#mjs-warnings

[loganfsmyth]

Yeah, I'm actually 100% for .mjs as a format, my concern is more that tooling adopting it without rules for how interop works seems dangerous. If Webpack itself for instance only allowed .mjs files to import other ESM files, I'd have zero concerns.

In the end though, I do think this PR is something we should just land, I just feel that the need for this PR indicates further pain for the community in the future, since people are going to adopt it expecting it to interop with CommonJS nicely, and that's still entirely undefined beyond experimental implementations.

Users are going to be pissed if all their code stops working in some future Webpack version.

[philipwalton]

I think those are very valid concerns. And I agree future pain seems likely ... I'm just hoping we can minimize it as much as possible.

[mathiasbynens]

because there's no guarantee that .mjs files publishes now would be compatible with Node's eventual implementation.

The higher-order bit is that not using .mjs is not compatible with Node’s current implementation.

Modulo some proposals that were explicitly rejected (e.g. .m.js), there’s no guarantee about anything regarding Node’s eventual implementation, as it hasn’t been figured out yet. If I had to guess, I’d think it’s more likely that .mjs will continue to be supported by Node.

I think this discussion is orthogonal to this PR, though.