Fix exact "exports" and "imports" keys with no target falling back to a pattern

[kwy404]

Summary

matchSubpathFromExportsLike, used for both "exports" and "imports", looks up the exact subpath key first and only tries subpath patterns when there is no exact match. But it detects "no exact match" with target == null, so an exact key that exists but has no target is treated like a missing key. That happens when the value is null, or when it is a conditions object with no matching condition and no default (reduceExportsLikeMap reduces that to null). Metro then goes on to match a less specific pattern.

With this package:

"exports": {
  "./*": "./lib/*.js",
  "./internal": null,
  "./server": {"browser": "./server-browser.js"}
}

test-pkg/internal and test-pkg/server resolve to lib/internal.js and lib/server.js through ./*, with no warning. Node.js only tries patterns when there is no exact key, so it throws ERR_PACKAGE_PATH_NOT_EXPORTED for both. For the same shape in "imports" it throws ERR_PACKAGE_IMPORT_NOT_DEFINED (checked with require.resolve on Node 24.16). Metro already handles null pattern keys this way.

The fix checks whether the exact key exists (has) instead of whether its target is null. These subpaths are now reported as not exported or not resolved, with the usual warning and file-based fallback.

Changelog: [Fix] An exact "exports" or "imports" subpath with a null or unmatched target no longer resolves through a less specific subpath pattern

Test plan

Added a test to packages/metro-resolver/src/__tests__/package-imports-test.js. It uses "#features/*" plus an exact "#features/foo": null and an exact "#features/bar": {"browser": ...}.

• Before the fix it fails: #features/foo and #features/bar resolve to src/features/foo.js and src/features/bar.js through the pattern.
• After the fix both log the "could not be resolved" warning and then fail to resolve, as in Node.js.
• yarn jest packages/metro-resolver passes. scripts/jestFilter.js skips package-exports-test.js and most other resolver suites on Windows, so I also ran all 8 resolver suites with the Windows test fixes from Fix Windows-incompatible Jest tests #1937 applied locally: 125 tests passed. There, the "exports" example above resolved to lib/internal.js and lib/server.js before the fix, and to the warning plus the file-based fallback after it.
• flow focus-check, eslint and prettier --check on both changed files: clean.

[robhogan]

Thanks again!