feature request: could exports support array

[lovetingyuan]

{
  "exports": {
    ".": {
      "import": ["./dist/module.mjs", "./dist/another-module.mjs"]
      "require": "./dist/require.js"
    },
  }
}

for the "import" condition exports, could it be an array? if fail to resolve "./dist/module.mjs", then try to resolve next value, "./dist/another-module.mjs"

[ljharb]

Yes, arrays are always supported in any location, afaik.

[lovetingyuan]

Yes, arrays are always supported in any location, afaik.

But always the first file in array will be taken as result, right?

So, this lib does not care about whether the resolved file exsits on file-system, right?

[ljharb]

node will select the first one it can resolve (which yes, means it must exist on the filesystem), and I believe it will skip any unresolvable ones. I'm not sure what this lib does.

[privatenumber]

Seems Node.js hard errors on the first path that it cannot resolve:
nodejs/node#44282

Ideally, it would try the next path in the array.

[lukeed]

supporting this is a breaking change as it changes the API return type. saving this for the next major

personal opinion: it makes zero sense for this to be part of the specification. Author knows what/where each module can be found. Giving a consumer "alternatives" for how/where to find it + a "go pick & figure out which" seems very silly & undermines the "O(1) benefit" of ESM mapping.... If you're trying to offer a .tsx file instead of the .js equivalent (see linked vite issue), that is much better served by a custom condition (because I thought that was the point)

[privatenumber]

From reading the spec & Node.js discussions, the fallback array is only validated semantically so you still get very fast checks. For example, if the first entry is unsupported-protocol://file.js then it can be immediately be skipped to use the next one.

However, it's worth noting that TypeScript and Webpack both diverged from this behavior and actually try to resolve the paths before resolving the fallbacks.

For more details, I documented the behavior here in my own exports/imports resolver.

[lukeed]

I’ve followed too, thanks. I’m arguing that conceptually it doesn’t make sense. In your own example, there should never be a time where an author declares “lol://file.js” as a possible resolution. Every import should map to one thing depends on the conditions (including the how) it was imported