The "In defense of .js" option is missing
mikesherov opened this issue · comments
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.
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?
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.
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)
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.
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?
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.
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.
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
@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
@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?
@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.
@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.
@martinheidegger sure. Just saying it shouldn't be closed until a PR closes it :-)
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.
@qraynaud I have tried to make the reason for my writing clear in #11 (comment) please send a PR with how you would like to change the document.
In the defense of .js proposition, if I read it correctly, you can also replace index.js by module.js at your folder root to create a ES2015 module and it would work properly right away without the need for a package.json. It is really needed only if you want to load random files from the package directory like it is done with lodash.
And it supports fat packages (with both ES2015 & CJS versions in the same package) so it will not require a rewrite on NPM like for the package.json switch but is also fairly easy to implement. It is not really a lot harder than a if/else. You just have to look for module.js before index.js & look for module.root in the package.json to test if files are in module.root or not. That's fairly easy (maybe a 4 instead of a 3 since it's still not as easy an the .mjs approach I suppose).
This also makes the runtime argument a bit invalid. 2 is a hard note for something as trivial as checking if a file is in a subfolder or not.
In the same spirit, the education argument is not that valid. Understanding the root argument & the module.js vs index.js idea is not that hard.
The development argument is totally wrong too because now it's clear. Either a file is in the module.root folder or not. If everything is in ES2015 (module.js + no package.json) then there is no problem at all since module.root is implicitely ./
@qraynaud that would, however, break anyone who currently had a file named "module.js".
Yes. Only around 100 modules if I understood correctly their analyse. But it is still possible to decide package.json is mandatory but it might be sad for the ease of use the other way entails.
If the 100 modules or so have no dependants, then it's even easier.
100 modules on npm - there's still many modules not on npm that could break too.
Sure, but it gives you a %age anyway. It's very very very low.
The important thing to consider is that it's nonzero.
Someone please propose a PR if you have a clear idea of what needs to be changed. The earlier the better in particular if you are thinking the confusion is detrimental to your champion proposal: it needs to be fair, transparent and exhaustive.
@ljharb : I agree though, it needs to be considered carefully. But the right solution is not necessarily to aim for 0 disruption for such a huge change. But any disruption should be considered and weighted very carefully so it is obvious this should not got unnoticed.