Repository navigation
A question about this proposals #284
Description
Activity
The debate is over - ESM needs another extension, because the parse goals are ambiguous.
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
Reacted by Michael James (Kodhe)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.
Reacted by John-David Dalton, Andrea Giammarchi and Michael James (Kodhe)Reacted by Andrea Giammarchi and John-David Dalton@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.
@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.
Reacted by John-David Dalton@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
Reacted by John-David Dalton@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.
this is definitely not the place to argue about extensions
Reacted by Jordan Harband and Geoffrey BoothReacted by Jordan Harband
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?
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