actually discuss .cjs extension
#293
Comments
|
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://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 would, and others have already expressed their preference for an explicit The // 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? |
if the code is executed as ESM, regardless the
to me this mean
the purpose is to disambiguate |
|
Then you would have to use |
|
@adrianhelvik |
|
Okay. So the proposal is that:
Okay, get it. :) |
AFAIK that won't be the case since there are multiple ways to disambiguate Every argument made for |
|
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. |
not necessarily, accordingly to the current state, flags etc. In such context, In such context, every argument made for |
|
.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. |
audible gagging noises heard from twitter Most would see
This would advance the ecosystem default in a relatively easy-to-handle way, IMO, with |
|
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) |
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. Normally I would use Personally I use 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 It is not that Why is If you are okay with standard 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 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.
|
|
@targos Regarding .cjs, CoffeeScript has just as much trouble with it as CoffeeScript does with .mjs. It's 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. |
CJS is (was?) used for CommonJS modules in Node. It's not recommended now (nodejs/modules#293) but Node docs mention it (https://nodejs.org/docs/latest/api/modules.html#file-modules), so presumably some code out there uses it. Also Standard JS' pre-commit hook definition applies to such files with `files` rather than `type` (due to lack of identify support): https://github.com/standard/standard/blob/master/.pre-commit-hooks.yaml .
…sion 2.4.8 commit 939e9c9dab1217a54eedd6ac6e95273a0fbdfd66 Author: Anthony Sottile <[email protected]> Date: Thu Feb 3 15:14:30 2022 -0500 v2.4.8 commit 8a2d676fe9ca8a184b3ef32e0a793f80234aaebd Author: Adam Johnson <[email protected]> Date: Thu Feb 3 11:38:40 2022 +0000 Add cjs as a JavaScript file extension CJS is (was?) used for CommonJS modules in Node. It's not recommended now (nodejs/modules#293) but Node docs mention it (https://nodejs.org/docs/latest/api/modules.html#file-modules), so presumably some code out there uses it. Also Standard JS' pre-commit hook definition applies to such files with `files` rather than `type` (due to lack of identify support): https://github.com/standard/standard/blob/master/.pre-commit-hooks.yaml .
The
.cjsextension 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.
The text was updated successfully, but these errors were encountered: