Feedback on extension resolution

[ljharb]

It seems like a good idea to capture somewhere the feedback we receive on extension resolution.

[ljharb]

nodejs/node#27407

[ljharb]

nodejs/node#27408

[AlexanderOMara]

Is there any information available on why file extension resolution was disabled?

[GeoffreyBooth]

@AlexanderOMara See

• https://medium.com/@nodejs/announcing-a-new-experimental-modules-1be8d2d6c2ff#f606 (the Explicit Filenames section)
• https://nodejs.org/api/esm.html#esm_mandatory_file_extensions
• File extension/directory index resolution in ESM #268

[sheerun]

My feedback is that:

1. When I write import ./foobar then of course I want to import js file, not mjs, cjs, wasm, css, json, or other. This is also "what users are familiar with" as you noticed. If you want to introduce explicit extensions then please introduce them for all other file extensions than js.
2. Nobody is ever going to use url imports like https://unpkg.com/three@0.102.1/src/Three.js in Node. It's just silly thing in many aspects like reliability and security.
3. You can match browser behavior but it shoudn't prevent you from making convenient defaults for Node developers. After all you do it import so it supports resolving bare paths from node_modules. Why wouldn't you make good defaults for file extension as well? (i.e. resolve to js by default)
4. As node module author if I want to use modules I shouldn't be forced to change file extensions to mjs. Specifying in my package.json that js files in my module use ES6 modules (or specifying entrypoint to ES6 modules file) should be enough. Most node module authors already do it this way and node is late to the party to suggest some other way, especially totally not backward compatible with status quo and basically requiring module authors to rename every file in their repositories.
5. "There’s a performance cost to automatic file extension/directory index resolution": import doesn't do that anymore as described in this blogpost. It just looks for single field (package.main). Having js extension a default when no extension is provided also doesn't make performance worse.

So for the record I think forcing on community yet another .mjs and .cjs extensions was mistake to begin with and complicates already complicated landscape. Per-package configuration with package.type is already how it works so why on earth you require to confirm this additionally through renaming all files in repository. It's not like module authors will have half .mjs files and half .cjs files because even offical node docs now say we can't and shoudn't "mix them". Either all files in project will be in ES6 format or CJS format so no need for "file extensions" granurality.

[AlexanderOMara]

UPDATE: I think this is actually the biggest problem: #323 (comment) , #352

The below, while not super pleasant, could be worked around with smarter transpilers relatively easily.

---

Before, it was possible to write ES modules (or TypeScript modules), and publish both CommonJS and ES modules with a simple module transformation via babel (I've actually started doing this already, so my modules can be treeshaken).

Now we can't write:

import {foo} from './bar';
console.log(foo);

We have to write:

import {foo} from './bar.mjs';
console.log(foo);

Which means that now any transpiler also needs to rewrite the actual import path. I don't think any currently have this functionality, because until now this wasn't an issue.

This is very different from how the ecosystem has worked so far. For example, TypeScript and Webpack both work just fine with the extension-less module resolution. I would guess rollup does too.

---

I thought the previous design made much more sense.

When I import something, naturally I expect to get an ES module, preferring the .mjs extension, probably falling back on a .js CommonJS module exported as an ES module.

If I require something, naturally I expect to get a CommonJS module, preferring the .js extension which can't really be changed for backwards compatibility, probably falling back on loading a .mjs ES module exported as a CommonJS module.

I get that some people don't like the new file extension, but I don't think it makes sense to create new problems and add ambiguity just to keep it.

[MylesBorins]

Some feedback in favor of not having extension searching on by default

Twitter poll about compat: 65% of 1295 people favor Browser compat

@jhnns on twitter: https://twitter.com/Jhnnns/status/1003201464716726272

@mhart on twitter: https://twitter.com/hichaelmart/status/1039529625100185600
@brianleroux on twitter: https://twitter.com/brianleroux/status/1039653429272952832

Announcement tweet for PR had 150k impressions and no negative feedback

Tweet asking for feedback

Obviously none of this is scientific... but thought I could offer some balance to the feedback

[ljharb]

Again tho, enabling extension resolution does not in any way prevent “browser compat” - this is purely a question of whether you want the preferences of one group (browser compat folks) to oppress another (back compat folks) by making the feature off by default - because on by default causes no damage, but off by default does.