yosh

In that context, breaks are unacceptable. But also, you have to reposition what the developer expectations are here, given that there aren't strong preferences and what they have is working just fine.

React people started using ESM cause React told them to. They expect this syntax, they don't expect the spec's semantics entirely because they are running through compilers anyway.

The problem is that this doesn't work in Node.js today, so Node.js is violating a growing expectation of the developer community.

However, nobody expects to use a new file extension, so the Node.js proposal is already out alignment with expectations. Being that these aren't strong preferences we should expect adoption to be minimal and existing workflows to continue.

The npm proposal turns ESM adoption into a breaking change, which is not what I or anyone would expect when adopting new syntax. Again, people don't really give a shit about module syntax, so why eat a breaking change?

Back to the Node.js proposal, it drops hooks which breaks code coverage, another expectation violated when adopting it.

In summary, both proposals are making compromises that violate the expectations of the average developer. For something that most developers don't have strong preferences for that isn't a good idea.

Heh, agree pretty much with all this. Feel that nobody wants to make any breaking changes tho, but there's no other way to reconcile ESM with CJS. In that case choosing the path of least breakage would be desirable, right?