Repository navigation
Conversation
meta-cla
Bot
added
the
CLA Signed
facebook-github-tools
Bot
added
the
Shared with Meta
Contributor
|
@robhogan has imported this pull request. If you are a Meta employee, you can view this in D101985455. |
robhogan
approved these changes
Apr 22, 2026
Contributor
robhogan
added a commit
to expo/expo
that referenced
this pull request
Sep 15, 2026
# Why `forceNodeFilesystemAPI` does nothing in the fork. It's declared on `InputOptions`, `BuildParameters`, `WatcherOptions` and `CrawlerOptions`, and threaded from `FileMap` through `Watcher` into the crawler options, but no crawler reads it. Upstream removed it along with the native `find` crawler it used to select (react/metro#1693), and `@expo/cli`'s `createFileMap` fork never passes it. # How Removes the option and its plumbing, its `rootRelativeCacheKeys` case, and the test fixtures that set it. It was a `BuildParameters` key, so this changes the file map cache key - the first start after this change misses the existing file map cache, as upstream's removal did. # Test Plan ``` pnpm --dir packages/@expo/metro-file-map typecheck pnpm --dir packages/@expo/metro-file-map test pnpm --dir packages/@expo/metro-file-map lint ``` Typecheck and lint clean, 704 tests passed (18 suites). # Checklist - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
1 of 3 tasks
robhogan
added a commit
to kitten/metro
that referenced
this pull request
Sep 24, 2026
Resolves conflicts with react#1687 (symlink targets stored lexically resolved, as normal POSIX paths) and react#1693 (native `find` crawler removed). - The Node crawler keeps this PR's lazy `lstat` inside main's single `find` path. - Symlinks with a known `mtime` are still read eagerly by `FileMap#maybeReadLink`, which now stores main's format. A symlink crawled without an `lstat` is still `1` until a lookup traverses it, and `TreeFS#readSymlinkTarget` then reads it and stores the target in that same format, so a target read lazily and one read eagerly are indistinguishable. This replaces the `WeakMap`-based `#resolveSymlinkTargetToNormalPath`, which main removed. - The `find` binary tests are dropped along with the crawler they covered, the committed `types/` defs are dropped as on main, and the tests mock `node:fs` to match main's imports.
robhogan
added a commit
to kitten/metro
that referenced
this pull request
Sep 24, 2026
Resolves the conflict with react#1693, which removed the native `find` crawler: `findNative` is dropped, and `nodeCrawl` keeps this PR's flattened promise, calling `find` directly.
robhogan
added a commit
to kitten/metro
that referenced
this pull request
Sep 24, 2026
Resolves conflicts with react#1677, which rewrote the Node crawler: its crawler already checks the extension before `lstat` and builds normal paths per directory, so this PR's crawler change reduces to skipping the `lstat` for a file with no previous mtime, reading `previousState` from the crawler options. The crawler tests follow: new files are now recorded without an `lstat`, the filesystem root test checks the path passed to `ignore()` rather than `lstat`, and `forceNodeFilesystemAPI` (removed by react#1693) is dropped from this PR's new tests. Also updates the API snapshot for `FileSystem.getMtimeByNormalPath`.
robhogan
added a commit
to expo/expo
that referenced
this pull request
Sep 25, 2026
…50193) # Why Upstream removed `forceNodeFileSystemAPI` along with the native `find` crawler it used to select in react/metro#1693, first released in [Metro 0.85.0](https://github.com/react/metro/releases/tag/v0.85.0), and `@expo/metro-file-map` had already removed the implementation, just not the config. This is not user-observable, just part of unforking. # How Removes the option and its plumbing, its `rootRelativeCacheKeys` case, and the test fixtures that set it. # Test Plan ``` pnpm --dir packages/@expo/metro-file-map typecheck pnpm --dir packages/@expo/metro-file-map test pnpm --dir packages/@expo/metro-file-map lint ``` Typecheck and lint clean, 704 tests passed (18 suites). # Checklist - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
3 tasks done
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
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
This is a proposal to drop the native find binary crawler code path entirely.
We've recently dropped the native find binary crawler in Expo, which was accidentally activated in some cases. We discovered (which is particularly obvious on large projects/repos and
expo/expoitself) that it's consistently much slower than the Node FS crawler.To get into the "correct" preference and use the Node crawler, we're currently forcing
useWatchman: null, which then defaults to use watchman, if it's installed, but falls back toforceNodeFilesystemAPI: true. This is outside of what the types specify as valid, but is the cleanest way to disable the native find binary crawling.This crawler basically just adds overhead over the Node.js implementation and is consistently slower, and less efficient, while the Node crawler is pretty optimised already (and has very low overhead once #1677 is merged)
The timings of the native find binary crawler in
expo/expowas also observed to scale with the size of this repo, compared to a minimal reproduction, so the overhead isn't just limited to the child process call and result parsing.Changelog: [Internal] Drop native find binary crawler and remove
forceNodeFilesystemAPIflagTest plan