[metro-resolver] Import resolution `package.json` lookup for ESM is not Node module resolution compliant

[kitten]

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

We'd expect foo-pkg/bar to be resolving package.json:exports from foo-pkg/package.json first to check for exports. However, currently, it seems that Metro prioritises foo-pkg/bar/package.json

A lot of logic relies on getPackageForModule and getPackage which look up the package.json at the given absolute path, rather than taking the package path into account (as per the spec, see: packageSubpath being separated out)

Reproduction in the form of a unit test: https://github.com/kitten/metro/tree/%40kitten/fix/metro-exports-package-json-priority

[robhogan]

Thanks for the report (and tests!).

Yeah, I agree this is a bug. A lot of the implementation has this assumption that we can convert candidates to absolute paths early and we lose the context of "package root".

It's fixable - one complication is deciding how exports resolution should interact with the "browser field spec", which Metro and most bundlers have implemented forever and which Node.js doesn't.

The most straightforward option is to say that the presence of an exports field in the root package.json completely sidesteps browser spec redirection, but I'd want to make sure that's consistent with other bundlers before shipping it as a "fix".

[kitten]

I did have a quick look, and it sure doesn't seem trivial 👍 We've discovered this due to the swr package. They seem to be doing what I implemented a long time ago in urql's packages as well, where the nested package.json is a fallback for missing package.json:exports support and points to ../ relative paths. We noticed that it was taking precedence because we don't support package.json:module properly (I've got a PR that forcefully adds it when isESMImport: true is received, among other additions).

It seems like the package.json:exports taking precedence though is explicitly different to all other resolution modes, which is definitely a little annoying. I haven't yet looked at how other bundlers solve it, but I suppose the problem here is the amount of customisation Metro offers right now (which we're also trying to partially lock down going forward in Expo, since a lot of them are obsolete with some fixes, package.json:exports support, etc having shipped)