Consider removing support for "default.js" directory lookups

[guybedford]

I really like that this proposal includes removing the file extension checks, as this will help get closer to code that works in browsers as well.

In line with this, it might be worth considering removing directory index support as well, although only for the "default.js" directory index.

The "default.js" would still be supported as the fallback package main though.

This way there is a forwards compatibility path to deprecating directory indexes entirely.

It would still allow CommonJS fallbacks (import "./x" -> "/x/index.js") allowing a gradual upgrade path of converting some package modules into ES modules while still supporting loading local CommonJS files.

The dual-mode subpath loads (import "pkg/x" v require("pkg/x")) can then need to be handled by import "pkg/x.js" and require('pkg/x.cjs.js') being distinct (or x.mjs and x.js).

@zenparsing would you be open to considering something along these lines? Can send a PR if you think it might be a worthwhile direction.

[zenparsing]

If we remove the directory "default" lookup, does it then (in the interest of simplicity) make sense to remove the package root "default" lookup and only use the package.json module key?

If so, it seems like this just becomes the "module" key proposal. Is that what we want?

I'm pleased that there is so much interest in making the module system interoperable between the browser and Node, but we should be wary of whether the pendulum has swung too far in that direction. It seems to me that directory default files ("index.js", currently) are a fairly commonly used feature in the context of Node, and it might be good to continue supporting them.

[guybedford]

If we remove the directory "default" lookup, does it then (in the interest of simplicity) make sense to remove the package root "default" lookup and only use the package.json module key?

No, this is very specifically about separating these two different cases (which are currently lumped together in Node's resolver):

import 'x'
import './dir'

The other scenario that can even be considered separately here is having import 'x/dir' being considered a separate case as well.

The point here being that the relative case is the one that CANT be mapped by a package map, so that ensuring relative specifiers are always exact isolates an important compatibility baseline layer.

This definitely keeps default.js as the default main.

We could even consider still allowing import 'pkg/dir' to also still do a default.js lookup as that would be possible to support through the package map. While this distinction may be more subtle easily see, it could be useful.

[zenparsing]

I think that it's essential that we have a really simple story. The details can be somewhat complicated, but if if the proposal has a simple story, it has a chance.

I think both of these are simple stories:

• "default.js" is the new "index.js", "module" is the new "main"
• "module" is the new "main", "index.js" is deprecated

The following story is more complicated:

• "module" is the new "main", "default.js" is the new "index.js" but only at the package root

From that point of view we might want to stick with the original story ("default.js" is the new "index.js")

[guybedford]

I don't think it makes it that much more complex:

• "module" is the new main, "default.js" is the new "index.js"
• automatic extension adding and directory index lookups are no longer supported

There are two basic things happening here - we are changing the names to ensure we can distinguish them, and we're removing features that stop browser compatibility.

I don't think the second part of the story is confusing, and should actually make intuitive sense to any users thinking about browser compatibility of their local requires (especially once package maps become tangible).

Not saying this is a must, but that it should be part of the conversation on this spec, possibly as a variation or similar.