Closed ljharb closed 5 years ago
Agreed. It went pretty quickly from what I considered a straw man to “a thing”. I’m in favor of keeping it but a quick, explicit discussion seems worthwhile.
On Wed, Mar 13, 2019 at 11:26 AM Jordan Harband notifications@github.com wrote:
The .cjs extension imo never received explicit consensus - it seems to have been discussed solely in side channels, and merged as part of a much larger PR that achieved consensus without mentioning this aspect of it.
Let's please discuss it, have it either reach consensus to keep it, or remove it.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nodejs/modules/issues/293, or mute the thread https://github.com/notifications/unsubscribe-auth/AAio9KLlB_MFKwDc7oIc6h7LoPZr3Qtuks5vWULSgaJpZM4bvEDI .
I haven't made up my mind yet, but to me it just seems like nobody will actually use this extension.
FWIW
I haven't made up my mind yet, but to me it just seems like nobody will actually use this extension.
I would, and others have already expressed their preference for an explicit .cjs
over .mjs
.
The .cjs
extension is also one of the best ways to migrate older projects/dependencies or keep these as such.
// modern JS
import legacy from './module-name.cjs';
// module-name.cjs
module.exports = require('module-name');
That will disambiguate without needing any change to already published CJS modules.
I don't see how this would change anything. Okay, allow it if you like it, but we'll still need mjs to determine which parser to use. To me, this would just mean .js == .cjs. Which I have absolutely no opinion about. Is that the purpose?
we'll still need mjs to determine which parser to use
if the code is executed as ESM, regardless the .mjs
extension, .cjs
determines the parse goal of the legacy/intermediate imported file.
To me, this would just mean .js == .cjs
to me this mean .js
can be the present and the future, and .cjs
imported at any time though a single, intermediate, file, for any legacy module that doesn't offer an ESM counterpart.
Is that the purpose?
the purpose is to disambiguate .cjs
from ESM, same way you'd use .mjs
to disambiguate from CJS.
I'd personally write everything as ESM using .js
extension and explicit import legacy dependencies without an ESM counter part through an intermediate .cjs
file.
Then you would have to use --module
or something to determine the parse goal, or break all legacy apps.
@adrianhelvik alias node='node -m'
would work great for me 👋
Okay. So the proposal is that:
Okay, get it. :)
By default .js == .cjs
AFAIK that won't be the case since there are multiple ways to disambiguate .js
, but the proposal is that .cjs
will disambiguate CJS no matter what, same as .mjs
disambiguate ESM no matter what.
Every argument made for .mjs
is valid for .cjs
too.
That’s not exactly accurate; the argument for .mjs is that .js means cjs already. The argument for .cjs, as i understand it, only exists when a mode is enabled that changes the meaning of .js to mean ESM.
.js means cjs already
not necessarily, accordingly to the current state, flags etc. .js
can be parsed as ESM and mean ESM.
In such context, .cjs
will disambiguate CJS no matter what, same as .mjs
disambiguate ESM no matter what.
In such context, every argument made for .mjs
is valid for .cjs
too, so there's no reason to not have it.
.mjs is the future. .js interpreted as esm on a per project basis is good for interop and .cjs fills in the little edge case of someone needing CommonJS, but not wanting to change the extension of all their files.
To me, .js as esm on a per package basis sounds like a small feature that would ease the transition for a lot of people in the short run. (before .mjs becomes widespread) .cjs is a natural extension of that.
.mjs is the future
audible gagging noises heard from twitter
Most would see .mjs
as vestigial and hope that at some point in the future .js
as esm
could become the default. Take this reasoned transition plan, for example:
type
field is available unflagged in node
12. npm --init
starts to generate package.json
files with "type": "module"
set.node
13 - warn on packages without "type":
set to a known value ("module"
or "commonjs"
). npm
automatically adds "type": "commonjs"
to packages missing the field on installation, so most people don't actually notice the change.node
14 - "type": "module"
or "type": "commonjs"
is now a required package.json
field.node
15 - Packages missing a "type":
field are now assumed to be "type": "module"
by default. npm
now automatically only appends "type": "commonjs"
to packages last updated prior to a specified cutoff date (and does nothing to modern packages).This would advance the ecosystem default in a relatively easy-to-handle way, IMO, with npm
's coordination. Many would argue that .mjs
is a technical crutch - not the future.
Okay, that does not sound too bad to me. But why is .mjs so bad? Have you actually tried it. It's quite simple really. Just use the mjs extension.
Try it out on two pet projects and get back to me.
Okay, that does not sound too bad to me. But why is .mjs so bad? Have you actually tried it. It’s quite simple really. Just use the mjs extension.
Try it out on two pet projects and get back to me.
Yes, I tried it: https://github.com/nodejs/modules/issues/151#issue-340463837
.js means cjs already
This is only true for Node. As a passive observer of this discussion I just felt like this needs to be stated.
There are still other module systems besides commonjs. .js
means JavaScript. It doesn't unamibiguously mean any module system at all. Commonjs needs disambiguation just as much as ESM outside of the context of Node.
Normally I would use .cjs.js
or .amd.js
or .umd.js
, etc as a matter of convention. When writing modern standard JavaScript I never assume Commonjs as the default. It's what I transpile to from the standard format (ESM).
Personally I use .js
extensions in my source files because I'm writing standard JavaScript and I never write non-module scripts in the browser any more. In the browser I've moved on to this format and there is no need for disambiguation. I'd like to do the same in Node. Adding .cjs
just makes this transition easier as @WebReflection described. It also gives me an official extension to transpile my code to Commonjs with for users that aren't ready for this step. Just as I would use .umd.js
for legacy browser.
I'm not sure but it seems like opposition to this extension might stem from a code for Node first mentality. I think there are a lot of developers who code for other environments first and transpile to add support for Node.
To me it's not all about making a single codebase run in both environments. It's about being able to use the same conventions universally. So there is less supefluous context switching between projects.
@adrianhelvik Believe me I've been working with --experimental-modules
"sic" ever since they showed up (ie I only wrote module.exports in fenced code blocks) to the point that I stopped using TypeScript for the first time since that first showed up, and this is all bad.
It is not that .mjs
in isolation is bad — it is that .js
being coerced into this chronologically-baseless argument that CommonJS is default so it is wrong to even make a counter argument — but that counter argument is not if CommonJS "was" the default and rather now that there is a "standard" can CommonJS being the default be considered the remanence of an era where CommonJS was actually proposed to be the standard and did not become it. Just as the earth which was once flat, by default too.
Why is .mjs
bad, just consider the most fundamental implications of projects opting to block support for it even after it was registered, this is community fracture — ie yes it is bad.
If you are okay with standard .js
taking second place to non-standard anything, then consider the arguments of this monologue of a community member often presenting good and well-balanced debates.
I personally feel offended that anyone feels that this universal coding fabrication that we all share and only because of that projects including Node.js could have ever come to exist today, that it should ever yield priority or even be expected to consider it in the first place (sorry, that was very heartfelt on my part).
@targos This is actually 99.9% accurate to why we need it. As the modules team explored all the options (I mean everything presented by the community) we always end up with edge-cases for ambiguity (special cases where it is counter-intuitive to use any other of the out-of-band disambiguation options whatever that meant).
When the most reasonable way to "quickly" deal with ambiguity where it occurs is at a file level, this ambiguity will likely be causing either:
For this, the balanced foresight of .mjs
and .cjs
being the last resort not to be recommended 100% but expected in 0.1% of the time made sense to everyone when exploring different solutions — the only design that leads to .mjs
ambiguity only is the status quo that the modules team set out to correct.
I hope this clarifies the more constructive side of this debate, and I would encourage everyone to try to appreciate that there is always more to collaboration efforts that have involved far to many details and explore all too many ideas floating about in the community.
I encourage and welcome more of these kinds of constructive questions posed to members of the @nodejs/modules and involvement from everyone in our community.
GeoffreyBooth I do not understand the problem with CoffeeScript. If it just compiles the code without knowing the parse goal, people who want to mix cjs files with esm will have issues anyways, because there's no way to know what extension each output file should have.
"type": "module"
to the projects
package.json`.coffee --ext mjs
would output files with the .mjs
extension instead of the default .js
.@targos Regarding .cjs, CoffeeScript has just as much trouble with it as CoffeeScript does with .mjs. It's "type": "module"
that solves the problem for CoffeeScript.
I can't add a new option, e.g. for output file extension, because the ecosystem of CoffeeScript build plugins (Webpack, Gulp, Meteor, Vue files in Meteor, etc. etc.) would all need to be updated to support it, and many of those plugins are abandoned.
Closing as I believe this was covered in the last meeting. Please feel free to re-open or ask me to do so.
The
.cjs
extension imo never received explicit consensus - it seems to have been discussed solely in side channels, and merged as part of a much larger PR that achieved consensus without mentioning this aspect of it.Let's please discuss it, have it either reach consensus to keep it, or remove it.