Resolver: Observe Haste names under unstable_incrementalResolution

[robhogan]

Stacked on #1949.

Summary

#1949 records what a resolution looks up in the file map. It doesn't record Haste lookups, which aren't paths - the resolver asks the Haste map for a module or package by name, for every bare specifier when allowHaste is set. A module of that name appearing later changes the result, so the name needs observing whether or not it was found.

This adds haste to ResolutionObservations, the set of Haste names a resolution looked up. They're recorded in the two Haste closures that ModuleResolver already creates per resolution, so nothing else changes and the resolution context is untouched. It's the bare name that's recorded, not the platform - HastePlugin falls back from the platform to native and then to the generic module of that name, so a change to any of those bindings can change the answer. Haste packages share the bucket, since they share the namespace.

metro-file-map doesn't change. Its Observations is an interface, and Metro's record is a wider type that satisfies it, which is why that type wasn't exported.

Two things keep this cheap:

• Nothing is observed when no file can be given a Haste name - no hasteImplModulePath and enableGlobalPackages: false, which is Metro's default. The Haste map is empty then and always will be, so every lookup is a guaranteed miss, and recording one per bare specifier would be paying to observe something that can't change. createModuleResolver works this out from config, by the same rule HastePlugin's filter uses.
• The set is created on the first name recorded, and haste is null until then. Most resolutions are relative imports that never consult Haste. Allocating a set for each when Haste is enabled cost ~0.9MB on the benchmark app for ~0.2MB of entries.

Nothing reads these yet. Invalidating from them needs HastePlugin to report which names changed binding in a batch - it's the only thing that knows, since a removed file's name is gone from the map by the time anyone else sees the change event. That's to follow, alongside invalidation generally.

The empty module is resolved with allowHaste: false, so it observes no names and there's nothing to merge for it.

Benchmark

Resolution time in isolation, flag on in both columns, through the whole-resolution cache (see the test plan). No measurable cost either way - everything is within about half a percent, inside the run-to-run spread.

scenario	#1949	this diff	#1949, Haste enabled	this diff, Haste enabled
first build (ms)	112.4	111.8	111.2	110.6
rebuild, nothing changed (ms)	7.75	7.78	7.81	7.79
after a source edit, the edited module's dependencies (µs)	177	168	170	172
after a package.json change, re-resolving everything (ms)	93.2	93.2	93.6	94.1
heap retained after resolving (MB)	18.8	18.8		19.1

With Haste enabled, 27% of distinct resolutions look up a name (1.9k of 6.9k), one name each, over 72 distinct names. With it inert, no resolution carries a set.

Test plan

yarn jest packages/metro-file-map packages/metro-resolver packages/metro/src/node-haste packages/metro/src/DeltaBundler packages/metro/src/integration_tests
yarn flow check
yarn typecheck-ts
yarn verify-api-snapshots

New tests in resolver-test.js: nothing is observed when no file can be given a Haste name, a name is recorded when it's found and when it isn't, a deep import records only its package name, a relative import records nothing, and a global package name is recorded. The existing exact-set expectations gain haste: null.

Benchmark app - a synthetic mid-size RN 0.87 app: 23 common dependencies (Reanimated, React Navigation, TanStack Query, lodash, etc.) and ~1,000 generated first-party modules, 60% of them in a workspace package outside projectRoot with its own node_modules. The iOS dev bundle is 2.8k modules, from a file map of 34k files. Timings replay the resolveDependency calls a real build of it makes against a fresh DependencyGraph per process, in interleaved rounds, with source and package.json edits made on disk and picked up by the watcher. "Haste enabled" is the same app with enableGlobalPackages: true, which gives its first-party packages Haste names. These timings isolate resolution - no transformation, serialisation or file reads are included. A real build of this app takes around 4s even with a warm transform cache, so resolution is about 2% of it.

Changelog: Internal