But if node.js were to use a different default of how to do filesystem lookups (look for foo.js, then fallback to foo/index.js if not found), then you'd start seeing modules which wouldn't work on the web without the web server setup to use that exact same system. That's now an implicit contract.
This is in all honesty a small problem in the grand scheme of things, and it's one that can be equally solved by better editor tooling (for auto-refactor filenames abilities that also change all imports, since imports are for the most part statically analyzable now)
> But if node.js were to use a different default of how to do filesystem lookups (look for foo.js, then fallback to foo/index.js if not found)
They won't do that because they are clearly intent on having code work between environments. They repeatedly tell people this whenever people complain about .mjs. So we can discount this as a possibility.
> you'd start seeing modules which wouldn't work on the web without the web server setup to use that exact same system. That's now an implicit contract.
The inverse is true for their .mjs solution, which is essentially "Use Node's .mjs on the web or shared code will break in Node". This requires adopting the Node naming convention on the web and altering web servers to serve .mjs files as application/javascript. The .mjs file extension isn't a standard and doesn't make sense on the web; ESM modules are both of those things. If you think changing web server configurations for an implicit contract is not acceptable, you should be against .mjs.
This is in all honesty a small problem in the grand scheme of things, and it's one that can be equally solved by better editor tooling (for auto-refactor filenames abilities that also change all imports, since imports are for the most part statically analyzable now)