No, it's a problem because the formats are fundamentally incompatible and it's impossible to infer the author's intent. A package with no imports/exports or requires could be either ESM or CJS and no heuristic can solve for that reality.
How common are packages with no imports, exports, requires, or "module.exports="?
I imagine that's quite rare, because such a package would only be imported or required for its side effects; and because that package cannot import or require any others, could you safely just assume that if it was `require()`ed use CJS, and if it was `import`ed, use ESM?
Rare things still happen a lot at the scale of npm. And due to transitive dependencies it winds up affecting a lot of actual users. And this is just one example of an incompatibility, there are many more. Bun didn't discover a silver bullet here that dozens of other tools in the past missed on.
Do you have an empirical basis for that? I'm curious because on one hand, Bun is advertising they are solving a major challenge for library authors, really betting quite heavily on that being persuasive for adoption.
The risk for Bun's adoption is that they're wrong, of course.
The risk for Node's usage is that they're right, and library authors begin urging users to use Bun because it's 100x easier than making a useful library with Node. (This will happen very slowly, but things that happen very slowly can start happening all at once very quickly.)
Yeah, I don't believe GP. Their assertions that Bun hasn't solved this (or that the heuristic used is inadequate) are basically based on speculation without any evidence.
Assuming it has no imports or requires, and no references to meta, it’s a bare JavaScript file, and whether you treat it as esm or cjs shouldn’t matter, no?
JS has two top level grammars, one defaults to loose mode and the other defaults to strict mode, among other nuances.
Possibly the most devious nuance is whether the spec's appendix B applies, which affects whether html comment syntax is valid (yes, this is a thing). The html comment token can therefore be parsed either as a comment or as a series of operators depending on the grammar being used.
Effectively, this means it's possible to craft a program that does different things in CJS vs ESM mode.
