Repository navigation
[metro-resolver] Import resolution package.json lookup for ESM is not Node module resolution compliant #1582
Description
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
Activity
robhogan commentedon Sep 14, 2025
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
exportsresolution 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
exportsfield 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 commentedon Sep 14, 2025
I did have a quick look, and it sure doesn't seem trivial 👍 We've discovered this due to the
swrpackage. They seem to be doing what I implemented a long time ago inurql's packages as well, where the nestedpackage.jsonis a fallback for missingpackage.json:exportssupport and points to../relative paths. We noticed that it was taking precedence because we don't supportpackage.json:moduleproperly (I've got a PR that forcefully adds it whenisESMImport: trueis received, among other additions).It seems like the
package.json:exportstaking 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:exportssupport, etc having shipped)Nezz commentedon Oct 3, 2026
Hi! Any chance to look into this? We are hit with quite a number of packages when it comes to this like
zod, but it's packages with state likeswrwhere it actually break things and not just increases our bundle size.