ECMAScript Modules spec doesn't clearly state what to do with multiple extensions

[Scalahansolo]

Affected URL(s)

https://nodejs.org/api/esm.html#resolution-algorithm-specification

Description of the problem

While working through a few things with the Typescript team along with the vite / void zero team, I've run into something that I think could be clarified better in the docs about package resolution.

This is related to #60864 along with microsoft/TypeScript#62909 (comment)

What I'm trying to sus out there is... when these wildcard exports are used, should there be any type of "algorithm" or "probing" that should happen at resolution time if the import statement in the given file doesn't define the extension of the file being imported?

[aduh95]

Could you give a specific minimal example?

[Scalahansolo]

The example laid out in the linked Typescript issue I think outlines the issue well. Granted the errors that show up via tsc are not directly a node issue, it's more that it doesn't seem there it's well stated how these modules exports should be resolved.

[joyeecheung]

should there be any type of "algorithm" or "probing" that should happen at resolution time if the import statement in the given file doesn't define the extension of the file being imported?

I think you might be thinking about what's answered in https://nodejs.org/api/esm.html#mandatory-file-extensions - in Node.js, import does no extension probing for paths. It always only look at the path given as-is. The import conditions merely describe shorthands to expand, but once it's expanded to a path, the same rule would still apply - at least, from PACKAGE_IMPORTS_EXPORTS_RESOLVE in https://nodejs.org/api/esm.html#resolution-algorithm-specification it seems clear that there won't be any extensions being appended during the expansion and at most * are substituted. If it's not specified, it can be taken as "it doesn't happen".

[joyeecheung]

Closing as question answered.