actually discuss .cjs extension

[ljharb]

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.

[jkrems]

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 ***@***.***> 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 <#293>, or mute the thread <https:/notifications/unsubscribe-auth/AAio9KLlB_MFKwDc7oIc6h7LoPZr3Qtuks5vWULSgaJpZM4bvEDI> .

[targos]

I haven't made up my mind yet, but to me it just seems like nobody will actually use this extension.

[WebReflection]

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.

[adrianhelvik]

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?

[WebReflection]

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.

[adrianhelvik]

Then you would have to use --module or something to determine the parse goal, or break all legacy apps.

[WebReflection]

@adrianhelvik alias node='node -m' would work great for me 👋

[adrianhelvik]

Okay. So the proposal is that:

• By default .js == .cjs
• With -m/--module, project files will default to being interpreted as modules unless they use the extension .cjs or come from external packages.

Okay, get it. :)

[WebReflection]

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.

[ljharb]

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.

[WebReflection]

.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.

[adrianhelvik]

.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.

[weswigham]

.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:

1. type field is available unflagged in node 12. npm --init starts to generate package.json files with "type": "module" set.
2. 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.
3. node 14 - "type": "module" or "type": "commonjs" is now a required package.json field.
4. 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.

[adrianhelvik]

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.

[GeoffreyBooth]

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: #151 (comment)

[shannon]

.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.

[SMotaal]

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

[SMotaal]

@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:

1. An ESM to be treated as CJS.
2. A CJS to be treated as ESM.

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.

[targos]

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.

• If the CoffeeScript code base is written entirely in CommonJS, it already works with current Node.js and will still work in the future with the default configuration.
• If the CoffeeScript code base is written entirely in ESM, there are two options:
  • Add "type": "module" to the projects package.json`.
  • Add support in coffeescript for a custom extension. For example coffee --ext mjs would output files with the .mjs extension instead of the default .js.

[GeoffreyBooth]

@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.

[MylesBorins]

Closing as I believe this was covered in the last meeting. Please feel free to re-open or ask me to do so.