[kwy404]

Summary

Importing a package whose package.json has a non-object exports value, such as false, true or a number, fails the whole resolution with a raw TypeError: Invalid value used as weak map key. It happens with the default config, since unstable_enablePackageExports is on by default. Node.js ignores these values and resolves the same package through main.

{"name": "pkg", "main": "m.js", "exports": false}

normalizeExportsField only special cased strings, which can't be WeakMap keys, before caching its result. Booleans and numbers can't be keys either, but Object.keys() gives an empty list for them, so they reach _normalizedExportsFields.set(), which throws. Because that is a plain TypeError and not an InvalidPackageConfigurationError, the callers in resolve.js rethrow it instead of falling back.

This raises a config error for these values, so the existing handling warns and falls back to file-based resolution, which finds the same file as Node.js. Metro logs a warning where Node.js is silent, as it does for other invalid exports values.

Part of #2166 (the "exports": false row).

Changelog: [Fix] Fall back to file-based resolution, instead of throwing a TypeError, when a package's exports field is not a string, array or object

Test plan

Added a test to package-exports-test.js for false, true and a number. Before this change all three cases failed with TypeError: Invalid value used as weak map key. With the change they resolve to the main file and log one warning.

yarn jest packages/metro-resolver
Test Suites: 10 passed, 10 total
Tests:       327 passed, 327 total

Node.js 24 resolves main from both require.resolve and import.meta.resolve for false, true, 0 and 1.

eslint, prettier --check and flow focus-check pass on the changed files.

[github-actions]

Metro review: Looks good

Risk: low · Commit: 8fc741f · 4 commands run, in a restricted sandbox after an automated safety assessment

When a package's exports field is a boolean or a number, normalizeExportsField now throws the existing InvalidPackageConfigurationError. Before, it reached WeakMap.set and crashed with a plain TypeError. All three callers in resolve.js (package root/subpath, self-reference, and the shared resolvePackage path) already catch that error, log a warning and fall back, and null/undefined are filtered out before the call, so the guard covers every value that reaches it. The new tests fail on the base with the reported TypeError and pass on the head. Nothing needs changing.

No findings.

Verified

• ✅ yarn jest --no-watchman packages/metro-resolver (head) — 10 suites, 327 tests passed, matching the PR's test plan.
• ✅ yarn jest --no-watchman packages/metro-resolver/src/__tests__/package-exports-test.js (base, with the PR's test file copied in) (failed as expected) — All three new cases (false, true, 1) fail with TypeError: Invalid value used as weak map key. The base test file was restored afterwards.
• ✅ yarn eslint packages/metro-resolver/src/PackageExportsResolve.js packages/metro-resolver/src/__tests__/package-exports-test.js
• ✅ yarn flow check — No errors.

Not run: I didn't run the PR's claim that Node.js 24 resolves main for exports values of false, true, 0 and 1: the session's permission policy blocked my Node command because it used a shell variable. I didn't benchmark: the change adds one typeof check that only rejects invalid values, and it runs before the existing cache lookup, so it can't plausibly change resolver cost. I didn't run Windows: the logic doesn't depend on the platform.

_{Automated review by Claude. Advisory only: it never approves or blocks, and a maintainer makes the call.}