The "In defense of .js" option is missing

[mikesherov]

The in defense of .js option is actually a combo of the "whitelist/blacklist in package.json" option with "commonjs and es2015 in package.json" option.

Polling currently forces you to choose one of the options, which means you can't currently vote for the entirety of the proposal as is.

[martinheidegger]

I tried to reduce the list to have "the furthest developed" proposal of the bunch shown (instead of all x variants). As far as I can tell: the proposal which is listed in this repo as [4] specifies a module or main property and a modules.root which is a significant improvement over the complex older definitions it does still share the same traits (imho.). Packages still contain both syntax variants, you still have to research which file is which and both editors and users might be very confused by it.

Summary: I thought [4] is basically in defense of dot js. Would you agree? Could it be written clearer?

[mikesherov]

I thought it was 4+5. It matters because if you add 4+5 together, the only drawback is that scripts without package.json are still an issue. Taken separately, they each have drawbacks.

[martinheidegger]

It is always possible to implement two proposals. For example: It is possible to add a .mjs switch on top of a white-/blacklist where the white-/blacklist could be more or less important than .mjs. I see the [4+5] as similar combination that would introduce new problems in studying and combined create complexity that each by itself doesn't have. i.e. Even though the implementation of 4 and 5 was easy: the implementation of 4+5 might be hard and the combination of 4+5 would be less likely properly implemented by editors.

Does it make sense to keep the proposals as MVI's? (Minimum Viable Implementation)

[mikesherov]

I dunno. It seems to be unfair if you can only consider pieces of the proposal, and not the full thing because of an assumption of difficulty to implement. At the end of the day, the poll ideally should reflect options that were actually proposed, not component pieces of them.

[martinheidegger]

Hmm. In generally reduced the proposals to those which I thought made sense to understand the discussion. I don't see any benefit of [4+5] over [5] or [4] (the combination makes education worse, implementation worse, runtime worse, legacy package development worse,...). Maybe I am wrong?

[mikesherov]

Hmm. In generally reduced the proposals to those which I thought made sense to understand the discussion. I don't see any benefit of [4+5] over [5] or [4](the combination makes education worse, implementation worse, runtime worse, legacy package development worse,...). Maybe I am wrong?

You're creating a false dichotomy between 4 and 5. The in defense of JS proposal allows for easily switching to modules all at once (5), or switching to modules peacemeal (4). Both are important use cases the proposal covers. I don't have to chose one or the other.

[martinheidegger]

Correct me if I misread something but I can not find a passage in the in defense of JS proposal that would suggest that there is one single switch. Only in the unclosed issue 4f (disclaimer: written by me) there is an alternate variant that proposes the use of the single switch.

[robbiespeed]

Totally agree with @mikesherov, the In defense of .js proposal is not a "white/blacklist" and shouldn't be represented as such. With that in mind if "white/blacklist" were to be more representative of In defense of .js, I feel it should get higher marks in many areas on the comparison page:

Runtime

the CPU differences would be negligible, and even if you want to get nit picky, if a package were to use modules.root or module it's performance would actually go above .mjs since the extension would need to be checked on every file (.mjs should really be the one getting a 4 in this category, with the other 2 receiving a 5), where as at the very start it's determined that all files will be modules.

Education

module is essentially the new main I see no confusion there. modules.root has a similar simplicity. modules is only slightly more complex, but would likely be the least used of the 3. I think though that your proposal would be more complex (from what I can tell all commonJS code would need to be moved into a sub-directory which you define in the package.json), there's the learning curve of the new --syntax=CommonJS flag, and there would probably need to be a added flag on dependencies in the package.json that were fetched using that flag.

Development

Like I said above, it's very clear which files are ES6 modules. It has benefits over .mjs that directories would not be flooded with duplicate files, and they are placed in a clearly defined and separate path. I think In defense of .js deserves a 4 here.

As a side note I think you may be missing a complexity of your proposal in this regard (unless I'm missing something), how is one to migrate to ES6 modules piecemeal?

@martinheidegger in regards to the comment you just made, there is a single switch. Using modules.root or module describes all files to be imported as ES6 modules, here's the section that describes this

[martinheidegger]

@robbiespeed I happily agree that my formulation might be misleading or suboptimal (bad, more likely) and I welcome any PR that lays out the information clearer.

Lets start with why I called it white-/blacklist approach:
As developer: If you read the contents of a package that is not written by you, the folder structure does not give information on which file is ES2015 or which is CommonJS. In a defense of .js the specification of a the white-/blacklisting has been reduced to the minimum but it still means that I need to read the package.json and look for the module.root. module.root is a optional property which means that you could be working for a year without stumbling over a package with a module.root or a module and suddenly wonder why it works different in the first package that uses that feature. In 5 the type would be in every package that gets installed through npm and as a result you would immediately see the property in the package.json of files. Also, of the given approaches 4 is still the least likely one to be correctly implemented by tools and that will impede the development.

Regarding performance I should mention that the difference between the approaches is little on the grand scale of things and I chose integers to represent it which made it more like: is it worse than the others. Rethinking what you wrote I tend to agree that it should be revised and hope for a PR.

I separated your comment about the complexity of 5 into the issue #16

And also I would like to point out: #15

[martinheidegger]

@robbiespeed @mikesherov Did I clear up my intention with the former comment? Do you still feel that the chosen options are not-okay? If so: Is it okay to close this issue and wait for PR's?

[mikesherov]

@martinheidegger i appreciate your feedback and comments. I really just want the existing information out there to properly display the actual proposals. To that effect, I don't think we can close this issue until a PR comes.

[martinheidegger]

@mikesherov Due to bias or lack of understanding what is not clear, it is not possible for me to create a PR. I hope for a PR by you or the community which is why I added the "help wanted" label.

[mikesherov]

@martinheidegger sure. Just saying it shouldn't be closed until a PR closes it :-)

[qraynaud]

I think that the in defense of .js is more like 5 than 4 though it has some aspects of the 2. It has all the advantages you describe for 5 but does not require any change on NPM thus making the development effort on par with the mjs solution.

I believe the whitelist/blacklist should be removed (noone seems to want that to actually happen) and the switch improved to make it look like in defense of .js because it has the upsides of both solutions and not their downsides as much as I can see.