[robhogan]

Summary

Fixes a regression from #1945, which hasn't been released yet.

Since #1945, when resolving a file the resolver looks up the package scope of the files in a directory once and applies its browser redirections to every extension candidate. That's right for files, but a candidate can also be a directory that's a package root, e.g. ./bar matching bar.js/ with its own package.json. Before #1945 that candidate was redirected through its own package, so a browser mapping of "./" in bar.js/package.json applied. Since #1945 it gets the scope of its parent directory instead, and resolution fails.

This looks up the candidate first, and if it's a directory redirects it as a module of its own, like before. Files still share the directory's scope, so there's no extra getPackageForModule call unless a candidate is a directory.

Benchmark

Perf neutral with the same harness as #1945. Every 95% CI spans zero:

metric	mean Δ	95% CI
first pass	+0.1%	[-1.0%, +1.2%]
warm pass	0.0%	[-0.7%, +0.6%]
after a source change	+0.2%	[-0.2%, +0.6%]
after a package.json change	+0.1%	[-0.5%, +0.8%]
session: first build	-1.6%	[-5.6%, +2.6%]
session: full re-resolve after a package.json change	-0.4%	[-1.2%, +0.5%]

Changelog: [Internal]

Test plan

New case in package-scope-test.js: ./bar resolves through bar.js/package.json's "./" redirect to bar.js/replacement.js. It fails on main and passes here, and also pins the one extra getPackageForModule call, for the directory.

yarn jest packages/metro-resolver
yarn flow check

[cortinico]

cc @vzaidman as I have close to zero context here