Avoid auto-importing from barrel re-exporting index files that are likely to make an import cycle

[andrewbranch]

Fixes #45953
Slightly better version of #47432

Essentially the same logic as #47432, but does it by file location rather than computed module specifier to allow for non-relative specifier preferences with baseUrl and paths and symlinks.

[fatcerberus]

If this is specifically just de-prioritizing stuff like ../.. as suggested in the description of #47432, won't the problem show up again with e.g. nodenext when the offending import would be instead ../../index.js?

[andrewbranch]

This is not looking for computed module specifiers, but it does treat files named "index" specially. See the conversation near the end of the linked issue. Only --moduleResolution node gets this behavior because in other modes, I don’t think it makes sense to make assumptions about files named "index." A module specifier like ../../index.js generally doesn’t have this problem anyway, because it has the same number of directory separators as ../../foo.js, so the latter will be sorted first anyway. But yes, this does not universally solve the problem of creating an import cycle with auto-imports, but it should make it less likely for common scenarios.

[fatcerberus]

I don’t think it makes sense to make assumptions about files named "index." [in modes other than --moduleResolution node]

That's fair, you're not as likely to have index.js be a barrel if you have to name it explicitly, and if there is a barrel somewhere in there it'd probably have a more descriptive name. That being said, it might be an issue for CommonJS projects migrating to ESM since the index.js will exist for historical reasons. ../../foo.js may be sorted first, but ../../quux.js would be sorted after (assuming alphabetical sorting).

[andrewbranch]

It’s not alphabetical sorting, it’s program order, so re-exports come second unless there’s a reason to prefer them (i.e. fewer directory separators).

[sandersn]

Basic idea sounds right to me. The code looks good as far as I am familiar with it -- but I have to relearn it a bit every time.

[sandersn]

toPath is used as a way to get the current directory and getCanonicalFileName from the provided host as far as I can tell. Is that basically right?

[andrewbranch]

Yeah. I think the current directory is never used in practice in this context. What it’s going to do is lowercase stuff.