Conversation
Summary: Add `generated` via SignedSource to generated TypeScript definitions + hint at how they're generated. Replace `format` with `noformat` just to avoid a potential conflict between OSS prettier and our generated output. Reviewed By: huntie Differential Revision: D93416787 fbshipit-source-id: 964b5334da5033e423b27062ae017bc93c451a9c
Summary: X-link: facebook/react-native#55791 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D94566027 fbshipit-source-id: 004fe345615f2f9f22aa40cf818788e94726ed19
Summary: [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: marcoww6 Differential Revision: D95440622 fbshipit-source-id: 827f1a20c4cddcc93a74ad8630acd89c1b13deb7
Summary: Pull Request resolved: #1665 X-link: facebook/react-native#55948 js1 flow-runner codemod flow/transformTypeParamBound --format-files=false xplat/js Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D95429551 fbshipit-source-id: 6f5694fed74364c6f1c58e28376c86eae6201366
…#1638) Summary: Update the Metro Babel transformer to generate cache keys that include the contents of user Babel configuration files, ensuring cache invalidation when Babel configs change. This is similar to what Jest does and it seems to work really well for them. Metro changelog: [Fix] Include user-defined babel config in transformer cache key to ensure correctness Changelog: [Internal] bypass-github-export-checks Pull Request resolved: #1638 Reviewed By: vzaidman Differential Revision: D90469997 Pulled By: robhogan fbshipit-source-id: 44d06e7ec873988bcd0dff61ec13318d20f7223b
…orkspace Reviewed By: cortinico Differential Revision: D95530282 fbshipit-source-id: a4b8b57acd67a31e32e6881e3f0a881c8f747b98
Summary: Tests often involve the server or filesystem and a bit flaky. Only fail them after 3 tries. Changelog: Internal Reviewed By: GijsWeterings Differential Revision: D94683493 fbshipit-source-id: a48b5525fba05f52ce7e6d3a6b641772b39b2ffa
Summary: fixed test not running inside "act", also fixed eslint issues Changelog: Internal Reviewed By: GijsWeterings Differential Revision: D94688211 fbshipit-source-id: 38ac8518adc4a9e1af66f60c8f2c4145d22c0de5
Summary: ## This stack Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory. However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves. ## This diff Adds optional mutation tracking to FileSystem's mutation methods via a FileSystemListener parameter, and add an implementation that aggregates *net* changes into a batch. The three file change maps are mutually exclusive, as are the two directory change sets. Changelog: Internal Reviewed By: vzaidman Differential Revision: D92006310 fbshipit-source-id: c60638013bec58a98a7184da3cd8ea3df4d97a42
…rocessing Summary: ## This stack Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory. However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves. ## This diff Uses the new `FileSystemChangeAggregator` to track files added/modified/and removed during crawl (ie, between one startup and the next, with or without a cache), which cleans up some ad-hoc Reviewed By: vzaidman Differential Revision: D92047480 fbshipit-source-id: 319a8328b18097b8ceeb7cd85a3f9d474418fdfa
…mmediately before each emit Summary: ## This stack Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory. However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves. ## This diff Currently, internal file map structures like `FileSystem` and plugin data are updated as soon as an event from the OS is processed, but then we wait (and potentially process more changes) to debounce them, before emitting `'change'`. This makes it difficult to aggregate a sequence of changes into a net change (pushing that responsibility onto the consumer). As an intermediate step, this reorders things so that we internally enqueue events due to be emitted in the next batch, and only update internal structures immediately before emitting `'change'`. As a bonus, this means consumers cannot observe changes in between `'change'` events - all state is consistent with the most recently published event. Changelog: Internal Reviewed By: vzaidman Differential Revision: D92008990 fbshipit-source-id: 18c14551a727b54cddbe95a69d14336e66824f5b
…ectly
Summary:
## This stack
Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory.
However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves.
## This diff
Consolidates the plugin update API from three separate methods (`bulkUpdate`, `onNewOrModifiedFile`, `onRemovedFile`) into a single unified `onChanged(changes: ReadonlyFileSystemChanges<T>)` method.
Previously, plugins implemented three different change handlers:
- `bulkUpdate(delta)` for batch processing with `{addedOrModified, removed}` iterables
- `onNewOrModifiedFile(path, data)` for individual file additions/modifications
- `onRemovedFile(path, data)` for individual file removals
This diff replaces all three with a single `onChanged` method that receives a `ReadonlyFileSystemChanges` object containing categorized change iterables: `addedFiles`, `modifiedFiles`, `removedFiles`, `addedDirectories`, and `removedDirectories`.
Key benefits:
1. **Simpler plugin interface** - One method instead of three reduces boilerplate and implementation burden
2. **Richer change semantics** - Distinguishes added vs modified files (previously conflated in `addedOrModified`)
3. **Directory tracking** - Exposes directory add/remove events, enabling future features like incremental resolution invalidation based on directory existence
Also moves `DependencyPlugin-test.js` and `dependencyExtractor.js` to colocate test fixtures with plugin tests under `plugins/dependencies/__tests__/`.
Reviewed By: vzaidman
Differential Revision: D93984442
fbshipit-source-id: 6aee9b9c87b5a5f7fd32a157a324160b1c329eb0
…ngeAggregator and reduce duplication Summary: ## This stack Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory. However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves. ## This diff A bit of misc refactoring that decouples things from the `eventsQueue` we're about to remove. Reviewed By: vzaidman Differential Revision: D94076918 fbshipit-source-id: 944a523ae67d9dcb78c106d410bb7205abd4204a
…ventsQueue, update tests to use new API Summary: ## This stack Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory. However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves. ## This diff Expose the new `ReadonlyFileSystemChanges` (structured net change) to `metro-file-map` consumers, and update tests etc to assert on it rather than `eventsQueue`. Retain `eventsQueue` to split up this migration, and we'll kill it in the next couple of diffs. Reviewed By: vzaidman Differential Revision: D94077032 fbshipit-source-id: 2440f9f205a872187cc0aded9f3a155712b7a28b
…eEvent API Summary: ## This stack Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory. However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves. ## This diff Refactors DeltaCalculator tests to use the new `ChangeEvent` API with structured `changes` and `rootDir` fields, replacing the deprecated `eventsQueue` format. Changelog: [Internal] Reviewed By: vzaidman Differential Revision: D95057371 fbshipit-source-id: 1b2614dbe364c16d72cc266aab519ce40a34e39f
…Queue Summary: ## This stack Directory creation/deletion events are essential to efficient incremental resolution, because the resolver uses non-existence of a directory (like `node_modules`) to skip dozens of file existence checks under that directory. However, directory addition/deletion is reported inconsistently at the operating system level, and any low-level tracking must be implemented separately for each watcher. Instead, we'll reorganise things so that file events are passed to `FileSystem` (`TreeFS`), and *it* reports what changes are actually made to the in-memory representation, including which directories are added/removed. This turns out to be cleaner for file events too, and unlocks fixes like better handling of directory moves. ## This diff The `eventsQueue` in the payload of `metro-file-map` `'change'` events is deprecated in favour of the new, structured `changes` and `rootDir` props. The previous diff migrated the main consumer of file map events in Metro (`DeltaCalculator`), this diff migrates the remaining ones - package cache invalidation and a couple of internal uses. We can then kill `eventsQueue` as a non-breaking change because `metro-file-map` is semver-experimental, and the events are not otherwise public. This completes the stack, with robust, consistent directory change information now emitted alongside file changes, and provided to plugins. Changelog: [Internal] Reviewed By: vzaidman Differential Revision: D94080398 fbshipit-source-id: daf3f61d229402bdbdaadef2699e86a70f88e0fa
…imatch from 3.1.2 to 3.1.4 Summary: Fix CVE-2026-27903, CVE-2026-27904: Upgrade transitive dependency minimatch from 3.1.2 to 3.1.4 ## Summary Upgrading the transitive dependency `minimatch` from 3.1.2 to 3.1.4 to fix CVE-2026-27903, CVE-2026-27904. `yarn why minimatch` shows the following packages depend on it: - docusaurus/core > serve-handler > minimatch - docusaurus-plugin-internaldocs-fb > docusaurus-lunr-search > minimatch - docusaurus/core > react-dev-utils > fork-ts-checker-webpack-plugin > minimatch - docusaurus/core > react-dev-utils > recursive-readdir > minimatch - docusaurus/core > shelljs > glob > minimatch **Note:** Resolution kept permanently in package.json because `serve-handler` pins minimatch at exactly 3.1.2 and the version reverts without the resolution. Reviewed By: huntie Differential Revision: D96169078 fbshipit-source-id: 5f33379196dc2de768b2274bb8b3aaf92dccdb6d
…imatch from 3.1.2 to 3.1.4 Summary: Fix CVE-2026-27903, CVE-2026-27904: Upgrade transitive dependency minimatch from 3.1.2 to 3.1.4 ## Summary Upgrading the transitive dependency `minimatch` from 3.1.2 to 3.1.4 to fix CVE-2026-27903, CVE-2026-27904. `yarn why minimatch` shows the following packages depend on it: - istanbul-api > minimatch - eslint > minimatch - eslint-plugin-import > minimatch - eslint-plugin-jsx-a11y > minimatch - eslint-plugin-react > minimatch - istanbul-api > fileset > minimatch - eslint > humanwhocodes/config-array > minimatch - eslint > eslint/eslintrc > minimatch - istanbul-api > fileset > glob > minimatch - babel-jest > babel-plugin-istanbul > test-exclude > minimatch Resolution was temporarily added, then removed. The version remains at 3.1.4 without the resolution. Reviewed By: vzaidman Differential Revision: D96167599 fbshipit-source-id: 709a487a38f87aa0266f3c5900b6f217de1c7083
Summary: X-link: facebook/react-native#56107 Bump hermes-parser and related packages to [0.34.0](https://github.com/facebook/hermes/blob/static_h/tools/hermes-parser/js/CHANGELOG.md). Changelog: [internal] Reviewed By: SamChou19815 Differential Revision: D96556729 fbshipit-source-id: fd6568de0efa43851c45584bba5a2c4ef49bfabe
Summary: X-link: facebook/react-native#56111 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D96799987 fbshipit-source-id: 2627c4d0d74bd82a096214d470c25fd0113880d7
…imatch from 9.0.5 to 9.0.7 Summary: Fix CVE-2026-27903, CVE-2026-27904: Upgrade transitive dependency minimatch from 9.0.5 to 9.0.7 ## Summary Upgrading the transitive dependency `minimatch` from 9.0.5 to 9.0.7 to fix CVE-2026-27903, CVE-2026-27904. `yarn why minimatch` shows the following packages depend on it: - typescript-eslint/typescript-estree - typescript-eslint/parser (via typescript-estree) - eslint-plugin-jest (via typescript-eslint/utils/typescript-estree) Resolution was temporarily added, then removed. The version remains at 9.0.7 without the resolution. Reviewed By: vzaidman Differential Revision: D96166502 fbshipit-source-id: f1dcd8477ac9f0576b9fb2d6fda1498798ecef91
…moved Summary: Now that we have a change listener on `TreeFS`, we can delete multiple entries during a `remove()` call without losing information about what was removed. Use this to implement the natural behaviour of deleting a non-empty directory, where we now recursively delete contents instead of throwing. This fixes a macOS, non-Watchman bug in the handling of a non-empty directory being moved outside a watch root. Previously, we would only receive the a directory "rename" event from the OS, which we would ignore, and Metro would still "see" the directory contents at their old location. Changelog: ``` - **[Fix]**: macOS + non-Watchman: correctly detect contents as removed when a watched directory is moved. ``` Reviewed By: vzaidman Differential Revision: D96202588 fbshipit-source-id: b8d41ca7b565b6b5c4df849c5178ab571df24ccb
Summary: Pull Request resolved: #1668 Modernise and cleanup this logic a little bit to reduce the noise of an upcoming change. Changelog: Internal Reviewed By: vzaidman Differential Revision: D96136859 fbshipit-source-id: ea02f2a529173ee31d0c6e7c56a56d828e8b0ed4
…g a subdirectory. Summary: In order to interpret low-level OS file events and emit an accurate set of changes to all affected paths, we sometimes need to fall back to recursively scanning a directory and comparing it with previous state. In Metro we have three watchers - Watchman, which has its own internal recrawl mechanism and always (/should!) give us a complete, high-level set of changes. - `FallbackWatcher`, currently used if Watchman is disabled on Windows and Linux, which implements flat inotify watches and *must* already internally crawl any "new" directories in order to watch them(*). - `NativeWatcher`, currently used if Watchman is disabled on macOS - uses `fsevents` to watch a whole tree *without* keeping track of contents. For `NativeWatcher`, if we receive a 'rename' event and we find that the path is a directory, it *may* be new and it *may* have contents. One approach would be for `NativeWatcher` to keep track of all files, internally scan any "renamed" directories, and emit any changes to files. However, that's redundant when we already have all of the mechanics for crawling, comparing with a previous state, and emitting the difference, downstream (because we do exactly that on startup, for current state vs cache). Here, we implement a way for a watcher backend to let downstream know there may be changes. Note that we don't need to worry about duplicate events (eg, a directory is created and immediately some contents are created - we might emit a new file event from the watcher as well as recrawling - but that's fine, because we aggregate changes at emit time). Changelog: Internal Reviewed By: vzaidman Differential Revision: D94241640 fbshipit-source-id: 1ae41f07f17fbec864953ee2111cb3872065e261
…ned (#1660) Summary: Pull Request resolved: #1660 Previously, when running on macOS without Watchman, when a directory was moved or cloned from another location (inside or outside a watch), the contents would *not* be detected by Metro at their new locations. That's because the OS only sends us a "rename" event for the directory, and no events for any of its contents (unsurprisingly, because they haven't changed). This stack introduces a new 'recrawl' event which watcher backends may fire when they are unable to determine whether the contents of an extant directory are new, and makes use of it in `NativeWatcher`. This does not apply to Watchman, which has its own (similar) recrawl mechanism, and it doesn't apply on Linux or Windows, which currently use a recursive watcher that crawl all "new" directories and compares contents to a tracked file map. Changelog: ``` - **[Fix]**: Detection of contents of directories moved or cloned into a watched location ``` Reviewed By: vzaidman Differential Revision: D94362228 fbshipit-source-id: d652c60539338efa273e196166b75b2327d4b114
… 2.3.1 to 3.0.2 Summary: Fix CVE-2025-69262: Upgrade transitive dependency pnpm/npm-conf from 2.3.1 to 3.0.2 ## Summary Upgrading the transitive dependency `pnpm/npm-conf` from 2.3.1 to 3.0.2 to fix CVE-2025-69262. ### Approach Rather than forcing `pnpm/npm-conf` to 3.0.2 via a permanent resolution (which would cross a major version boundary for its consumer `registry-auth-token@5.1.0` that expects `^2.1.0`), we nudged `registry-auth-token` from 5.1.0 → 5.1.1. Version 5.1.1 natively depends on `pnpm/npm-conf@^3.0.2`, and is within the existing `^5.0.1` semver range from `package-json@8.1.1`. ### Dependency chain ``` docusaurus/core (direct) → update-notifier@6.0.2 → latest-version@7.0.0 → package-json@8.1.1 (requires registry-auth-token@^5.0.1) → registry-auth-token@5.1.1 (requires pnpm/npm-conf@^3.0.2) → pnpm/npm-conf@3.0.2 ``` No permanent resolution was needed — the version sticks after removing the temporary resolution. ### yarn why output ``` pnpm/npm-conf@3.0.2 docusaurus/core > update-notifier > latest-version > package-json > registry-auth-token depends on it registry-auth-token@5.1.1 docusaurus/core > update-notifier > latest-version > package-json depends on it ``` Reviewed By: huntie Differential Revision: D96355741 fbshipit-source-id: 0b8873b01f472154f8d7240540f51ee3d758f7b4
…ro config Summary: Allow consumer-instantiated file map plugins to be passed in via Metro config. Changelog: ``` - **[Experimental]**: Add `config.unstable_fileMapPlugins` ``` Reviewed By: huntie Differential Revision: D95546247 fbshipit-source-id: 17a52abf76ae6c8fb5bde95c9bd2e77621cfe344
Summary: X-link: facebook/react-native#56169 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: marcoww6 Differential Revision: D97425290 fbshipit-source-id: 8118a167ab2c4e118214edbf6cdb5635d26c600f
Summary: Adds a `changeId` to HMR `'update-done'` messages, enabling clients to deduplicate actions that should only fire once per file change. **Motivation** This supports us re-adding a Fast Refresh update performance marker for React Native in D97486551. - Previously, this was reverted due to multiple `update-start`/`update-done` cycles firing when bundles were split. Changelog: ``` - **[Feature]:** Add `changeId` metadata on HMRClient `'update-done'` messages ``` Reviewed By: GijsWeterings Differential Revision: D97486552 fbshipit-source-id: 3c0aa69454b24a045c65ffaab4602a022adb9c4b
Summary: This diff reverts D97425290 issue with this version Depends on D97425290 Changelog: [Internal] Reviewed By: marcoww6, panagosg7 Differential Revision: D97534385 fbshipit-source-id: b76be68b58c891ce553f96b79c3fbf157085cf08
Summary: X-link: facebook/react-native#56203 Changelog: [Internal] Reviewed By: marcoww6, gkz Differential Revision: D97890708 fbshipit-source-id: 9547aca3b87c0cdfe5bf309cc964e3dd1712ca67
Summary: X-link: facebook/react-native#56224 Add standard Node.js stream properties to the Flow type definitions for `stream$Readable` and `stream$Writable` that were previously missing: - `stream$Readable`: - [`closed: boolean`](https://nodejs.org/api/stream.html#readableclosed) - [`destroyed: boolean`](https://nodejs.org/api/stream.html#readabledestroyed) - [`errored: ?Error`](https://nodejs.org/api/stream.html#readableerrored) - [`readableEnded: boolean`](https://nodejs.org/api/stream.html#readablereadableended) - [`readableAborted: boolean`](https://nodejs.org/api/stream.html#readablereadableaborted) - [`readableDidRead: boolean`](https://nodejs.org/api/stream.html#readablereadabledidread) - [`readableFlowing: ?boolean`](https://nodejs.org/api/stream.html#readablereadableflowing) - [`readableObjectMode: boolean`](https://nodejs.org/api/stream.html#readablereadableobjectmode) - `stream$Writable`: - [`closed: boolean`](https://nodejs.org/api/stream.html#writableclosed) - [`destroyed: boolean`](https://nodejs.org/api/stream.html#writabledestroyed) - [`errored: ?Error`](https://nodejs.org/api/stream.html#writableerrored) - [`writableEnded: boolean`](https://nodejs.org/api/stream.html#writablewritableended) - [`writableAborted: boolean`](https://nodejs.org/api/stream.html#writablewritableaborted) - [`writableFinished: boolean`](https://nodejs.org/api/stream.html#writablewritablefinished) - [`writableNeedDrain: boolean`](https://nodejs.org/api/stream.html#writablewritableneeddrain) - [`writableObjectMode: boolean`](https://nodejs.org/api/stream.html#writablewritableobjectmode) Docs: https://nodejs.org/api/stream.html These properties exist on all Node.js streams and are needed by Metro to detect when HTTP response streams have been closed by a client disconnect. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D98176491 fbshipit-source-id: 2407367c52e5ece9099289ffd18642bdc4a7047d
meta-cla
bot
added
the
CLA Signed
robhogan
force-pushed
the
0.83.6
branch
2 times, most recently
from
e27484b to
4a15ca9
Compare
Summary: X-link: facebook/react-native#56233 Applies the automatic fixes from the new `react-prefer-namespace-import` ESLint rule. Changelog: [Internal] Reviewed By: thegreatercurve Differential Revision: D98338132 fbshipit-source-id: 856dd5b96bfb7ab8398bdcbea3651435acbc891e
Summary: X-link: facebook/relay#5225 X-link: facebook/react-native#56260 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: SamChou19815 Differential Revision: D98556944 fbshipit-source-id: 5591ba00c5afeb107e9c4eb981fce1a9a3f22e9c
Summary: Pull Request resolved: #1672 Fix: #1671 Auto-generation of TS types dropped some hand-written exports that were never exported in Flow, so that upgrading from 0.83.3 to 0.83.5 broke some (advanced) users' TS imports. This restores the ones that were already implicitly part of the public API anyway. Changelog: ``` - **[Types]**: Restore type exports from `metro` that were previously TypeScript-specific ``` Reviewed By: hoxyq Differential Revision: D97315670 fbshipit-source-id: 70a44023f77066f81a5505dfa91d55cf51fd4460
Summary: Currently, `ModuleResolver` takes a `PackageishCache` in its constructor, which is an interface with `getPackage` and `getPackageOf`. `DependencyGraph` constructs the `PackageCache` and is responsible for invalidaiton. This refactors things so that only `DependencyGraph` is aware of the cache and `ModuleResolver` takes the two methods as simple function arguments, which makes incremental-resolution-safe lookups possible later in the stack. There is no behavioural change. Changelog: Internal Reviewed By: huntie, GijsWeterings Differential Revision: D97607062 fbshipit-source-id: 717a0d0f3e78849d4e38541240dc39da418513fa
…t Package Summary: Builds on D97607062 by renaming `PackageCache.getPackageOf` -> `PackageCache.getPackageForModule` and aligning the return value with the `ModuleResolver` `getPackageForModule` API, so that it can be used directly. This has the handy benefit of caching `path.dirname` results so that a cache hit needs no further processing, which saves ~3M `path.dirname` calls (~400ms) loading Meta's dependency graph - but the main motivation is simply to tidy up some unneccessarily misaligned APIs. Changelog: Internal Reviewed By: GijsWeterings Differential Revision: D97664960 fbshipit-source-id: ee873c0314cd867e020568774969a065214fc161
Summary: X-link: facebook/react-native#56286 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: gkz Differential Revision: D98860515 fbshipit-source-id: 196ffafcee417ac2949822848fe7752070a2c30a
…-hit allocations Summary: Optimize PackageCache: use Map/Set, cache null results, eliminate per-hit allocations ## Summary Refactors `PackageCache` with three optimizations that together yield a **19% speedup** (median) on `getPackageForModule` calls during `js1 build buckfiles`, despite switching from `Object.create(null)` to `Map`/`Set`. ### Changes 1. **Use `Map`/`Set` and `#private` fields** — Replaces `Object.create(null)` dict objects and `_`-prefixed fields with `Map`/`Set` and `#` private class fields for proper encapsulation. In isolation this is ~8-12% slower per-operation than null-prototype objects, but enables the optimizations below. 2. **Single-map result cache** — Replaces the two-map lookup pattern (`_packagePathAndSubpathByModulePath` → `_packageCache`) with a single `#resultByModulePath` map that caches the pre-built result object. Cache hits go from two `Map.get` calls + one object allocation to a single `Map.get` returning the cached object directly. This eliminates ~2.5M object allocations per build. 3. **Cache null results** — Previously, when `getClosestPackage`/`hierarchicalLookup` returned `null` (no enclosing `package.json`), the result was not cached, causing the same expensive tree walk on every repeat query. Trace analysis revealed that 123,017 unique paths (76% of all unique paths) have no enclosing `package.json`, and they account for 3,048,485 total calls (99% of call volume). Caching null results eliminates 413,138 redundant `hierarchicalLookup` calls, boosting the hit rate from 81% to 95%. 4. **Readonly return types** — `getPackage` and `getPackageForModule` now return `Readonly<>` types, preventing consumers from accidentally mutating cached objects. Reviewed By: huntie Differential Revision: D98745578 fbshipit-source-id: 3247bf39233c7fc556708fd8e2a0afd155b7a991
Summary: X-link: facebook/react-native#56318 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: gkz Differential Revision: D99477741 fbshipit-source-id: 3d3175111b128ae85c75db55d7e2f1d4bf3e1372
Summary: X-link: facebook/react-native#56392 [changelog](https://github.com/facebook/flow/blob/main/Changelog.md) Changelog: [Internal] Reviewed By: gkz Differential Revision: D100104742 fbshipit-source-id: 67480b4c5a52293b67fe0100b91496d67410f75f
Summary: Pull Request resolved: #1683 Currently this test fails on Windows, due to `flow-api-translator` mangling inserted comments when the input is on Windows but not CRLF delimited. We should fix this so that Windows developers can generate valid TS types for Metro, but the failing test is blocking OSS Metro releases so this is necessary mitigation. Changelog: Internal ___ overriding_review_checks_triggers_an_audit_and_retroactive_review Oncall Short Name: react_native_iroc Differential Revision: D100164030 fbshipit-source-id: 9a3324434cba3c5a413354dfda4cec7c586a7d24
Summary: X-link: facebook/react-native#56408 X-link: facebook/relay#5238 X-link: facebook/hermes#1978 X-link: facebook/flow#9396 Bump hermes-parser and related packages to [0.35.0](https://github.com/facebook/hermes/blob/static_h/tools/hermes-parser/js/CHANGELOG.md). Changelog: [internal] Reviewed By: bherila Differential Revision: D100198457 fbshipit-source-id: 06dcada56d61ae359c1d7a8362f80fdfb4e2d5b5
Summary: Adds tests for this functionality on the main branch, following #1682. Changelog: [Internal] ___ overriding_review_checks_triggers_an_audit_and_retroactive_review Oncall Short Name: react_native_iroc landed-with-radar-review Differential Revision: D100317490 fbshipit-source-id: b1f8b38d7981bac7a927d80d33a57310cd34e314
Summary: Pull Request resolved: #1685 Add a heartbeat mechanism, initially to prevent idle timeouts in (e.g) HTTP proxy configurations. Later we'll use it to detect broken connections. The client sends a periodic `{"type":"heartbeat"}` message every 20s; the server echoes it back. Although server and client versions potentially differ, this is non-breaking: - If the server doesn't recognise the `heartbeat` message, it simply ignores it. The client doesn't require a reply (yet). - The server never sends `heartbeat` except in reply, so a client doesn't need to support it. The server doesn't care if the client never sends it (yet). Changelog: ``` - **[Feature]** Add keepalive "heartbeat" message to Fast Refresh connections ``` Reviewed By: huntie Differential Revision: D100320458 fbshipit-source-id: 1ec1f8f7b8e238a89e8c7b2c734550cb82bde54f
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Prepare for hotfix release 0.83.6. Notable changes:
changeIdmetadata on HMRClient'update-done'messages (419bbf3)