The future of .mjs

[jpike88]

So I'm aware this is all still under the experimental flag and recognise its status as a result.

However, a fair amount of discussion is taking place across TypeScript and babel regarding where to direct attention with regard to modules.

microsoft/TypeScript#18442

A major point of uncertainty is whether or not the current ES Modules 'mode' and .mjs will continue on.

For what I can see, it seems like .mjs is here to stay. The goal of having a unified set of functionalites under a single file extension is obviously where you want to go, but .mjs/ES mode seems like the 'stepping' stone that will eventually make that a reality.

Is it possible to get a confirmation around how .mjs is to be treated, so basic file extension support can be approved with the caveat of it being experimental?

I'm one of I'm guessing many who have run with .mjs based projects, and would love to see a clear directive on this. It's been a long time coming I think.

[WebReflection]

I'm one of I'm guessing many who have run with .mjs based projects

Experimental flags should be used only to ... well, experiment.

This group exists because of the many discussions around the current status so that until it's "done", the only official statement should be: it's experimental and under discussion, don't use it in production.

That being said, and AFAIK, the current status is that there was some work done behind .mjs as parsing goal and TSC does not want to lose that work but the --mode=esm flag (or whatever will be called) will make .js files be able to be imported like any .mjs.

Same goes for info in package.json and yet nothing has been merged: it's under discussion.

---

OT: I like how everyone in that discussion ignored .mts option ... so you can imagine how many aren't happy with the .mjs one.

[benjamingr]

That being said, and AFAIK, the current status is that there was some work done behind .mjs as parsing goal and TSC does not want to lose that work but the --mode=esm flag (or whatever will be called) will make .js files be able to be imported like any .mjs.

As far as I understand (from the TSC discussion I've read) .mjs is pretty much here to stay (in terms of support) and we are exploring additional options to support as well as exact semantics based on use cases and our goals (like browser/node interop)

OT: I like how everyone in that discussion ignored .mts option ... so you can imagine how many aren't happy with the .mjs one.

That's because TypeScript already has modules (as pretty much the only option) and since TypeScript is built (ahead of time) it wouldn't be necessary.

[WebReflection]

As far as I understand .mjs is pretty much here to stay

maybe my answer was a bit too convoluted but I meant exactly this when I've written:

there was some work done behind .mjs as parsing goal and TSC does not want to lose that work

yet my point is that until it's under discussion, including the exploring other options bit, it doesn't make much sense to ask "a confirmation around how .mjs is to be treated" when .js files in some case could be treated exactly the same.

Locking external libraries/superset/languages over .mjs only isn't IMO a wise move at this time.

[devsnek]

ideally node's mode will be set such that .js is by default and we can use package boundaries and such and the only time you'll need mjs is when you want to mix cjs/esm in your source code

[jdalton]

much sense to ask "a confirmation around how .mjs is to be treated" when .js files in some case could be treated exactly the same.

Locking external libraries/superset/languages over .mjs only isn't IMO a wise move at this time.

Yep, as it is now .mjs adoption is a bit premature. Projects like InfernoJS and react-apollo have had to pull their .mjs code and revert to .js since it has broader ecosystem support. The safest route for .mjs support at the moment is to allow only bare bones functionality, like Babel 7 and Webpack 4, removing all interoperability and supplemental features. Projects, like TypeScript, are totally justified in waiting to see how things shake out in terms of features/support before extending support to .mjs.

[ljharb]

As much as I believe that .mjs is the best and a necessary default, and want to see it in use throughout the ecosystem, the worst thing that can happen is if it spreads through the ecosystem when there's still any possibility it could change (i'm looking at you, "module" and "jsnext:main" fields).

I think it would be ideal to avoid implementing .mjs support in any published code while it's still flagged in node.

[MylesBorins]

It is worth mentioning that many of us in this thread are representing our own views, as the modules team has not made any official recommendations to the project yet in regards to extensions.

As someone who has been involved in this for a while I do feel safe saying that ".mjs" is here to stay. It is easy to conflate ".mjs" with interoperability concerns, but no matter how we decide to do ESM + Common.js interop there is a need for an out of band mechanism for unambiguous modules. There is of course a potential future where ".mjs" is not adopted, but I personally don't see that happening.

@jpike88 do you consider your question answered? I think it would make sense to close this issue for now.

[demurgos]

Thanks for your answers. I'm also closely following the discussions around ES modules in Node. Even if I personally think that .mjs is the cleanest solution from a technical point of view, I understand the benefits of other solutions (such as package-scoped flags). I've read the issues mentioning that there are still ongoing discussions and modules may be finalized in a later Node version.
I'd just like to know if it means that there won't be any change regarding .mjs in the Node 10 release this month? It will still be available behind the --experimental-modules flag?

[WebReflection]

@demurgos I think @ljharb answered that already:
#57 (comment)

[jpike88]

Perhaps it's worth adding more information to the startup message when the flag is used? I've just done (probably the smart thing) a downgrade from using .mjs to using the esm loader... thing is it's taken me like 6 months to realise that it's the same thing. I'm not stupid, I promise.

Close for now, but my journey has ended using esm, converting everything back to .js and running with it has been painless and TypeScripe works solid with it.

Thanks all...

[demurgos]

Okay, I just wanted to be sure that "while it's still flagged in node." referred to Node 10 too.

[WebReflection]

a downgrade from using .mjs to using the esm loader

good choice for the time being since whatever happens esm can catch up beside node releases

thing is it's taken me like 6 months to realise that it's the same thing

yeah, .mjs is just the exact same JavaScript with import/export, instead of require, and an implicit strict environment. The esm loader can handle that pretty well (so does webpack, rollup, and others)