Modules: A question about this proposals

[voxsoftware]

I discovered this repository today. After seeing many proposals, I can say that almost all this proposals I implemented yet in one package

https://github.com/voxsoftware/kawix-core

Can review and determine if is a good valuable option for implement it?

1. use normal extensions .js for both: ESM and CommonJS
2. no require any special configuration on package.json
3. commonjs files will works without changes, like expected
4. esm files still will have access to variables: module,require,exports, ...
5. transpiled code is cached for ensure speed
6. imports are async
7. imports from URLs
8. imports from npm packages
9. imports from JSON is supported
10. typescript support without additional packages
11. all ES2017 syntax supported
12. can be added loaders, for add new languages and extensions. I have an example with .coffee
13. Can generate a single file bundle from an entire package, without a ton of dependencies like other solutions

My points 1, 2, 3 and 4 are clear: Stop the debate if ESM need another extension or if need specify in package.json the type of javascript file, etc. This should be simple, .js can be both CommonJS or ESM without any special change on file, extensions, or in other package files

[voxsoftware]

some of the proposals that can be related or solved in my proposal with my new module @kawix/core #150 #82 #70 #264 #255 #90 #214 #263

[ljharb]

The debate is over - ESM needs another extension, because the parse goals are ambiguous.

[devsnek]

very interesting project.

if you want to get involved further I suggest you check the readme for details on how to become an observer.

we aren't considering shipping a transpiler so I'm going to close this out. you might also want to take a look at a project another one of the members here is working on: https://github.com/standard-things/esm

[GeoffreyBooth]

Thanks for this @voxsoftware. It's interesting to see other people's priorities and solutions and how they would answer some of these same questions. You should definitely join this group.

@ljharb does not speak for the entire group. The parse goals are ambiguous, but there are many solutions for disambiguation besides extensions. We're working on a new implementation that uses several.

[voxsoftware]

@devsnek why not transpiler? In my project people can stsrt using all New features without any effort because include a transpiler., a New project called deno also include a transpiler for allow run typescript like my project. I think the most important is doing ESM transparent interop. If dont Want a full transpiler why dont include a transpiler that only parse imports and convert to code compatible with magic variables (module, e,xports, require) allowing people using without need a non standard way to specify the type of script. Browsers automatically imports js CommonJS and ESM without need diferentiate between. This is the way that Node should go.

[voxsoftware]

@ljharb imagine creating New extensions for each possible language that include imports ESM. For example coffeescript 2.why should be .mcoffee? No my proposal in @kawix/core is more elegant.

[voxsoftware]

@GeoffreyBooth check my project. I think that you Will love it. I am active developing this module. Is real a good choice for start including all New features today

[ljharb]

@voxsoftware yes, that’s how it should be. Every unique parse goal needs a new file extension, that’s literally their entire purpose for textual formats. A slippery slope argument doesn’t hold water here.

[devsnek]

this is definitely not the place to argue about extensions