The use of "no value" in this proposal is too casual
Closed this issue · 2 comments
In the proposal it states that
... there is no value but much complexity in also including an ES2015 version...
It is important for the discussion that value is use in the objective meaning: i.e.: It doesn't yield any benefit compared to other variants. The use here seems to be "its value is diminishable" or "compared to the other solution the value is not worth mentioning". I noticed upon that because for many people there is important value in it!
- If a person wants her open-source project to switch to ES2015 modules she expects that people write PR's etc. as ES2015 modules but just because she prefers ES2015 modules doesn't mean that she doesn't care about people who use old versions of Node.js. NPM supports node to 0.8 or so... for reference...
- If one package is stripped from the possibility to contain multiple dialects, the user-land will create packages like
async-es2015orasync-legacywhich shifts this discussion from here to npm and will cause an even more problematic feature/shift and fragmentation of the community. (how many -es2015 variant packages will the be in npm?)
Lots of folks already write their code and take pull requests in ES2015 module format and ship CommonJS modules. Having the CommonJS version be the runtime, doesn't preclude the ES2015 version from being the source. This is how Babel and TypeScript work today (and if you want to have both formats, you are almost certainly transpiling using one of these tools - trying to keep modules identical manually would be quite painful).
My proposal doesn't stop a package from having both types of modules in a package if that's what is wanted, but once you expect the runtime to load ES2015 format modules, then obviously this requires a newer Node.js runtime that supports them.
Changed the wording from "no value" to "little benefit"