Skip to content

metro-file-map: Let a lookup record a file it finds as content - #1951

Draft
robhogan wants to merge 1 commit into
robhogan/treefs-observationsfrom
robhogan/observe-content-lookup
Draft

robhogan wants to merge 1 commit into
robhogan/treefs-observationsfrom
robhogan/observe-content-lookup

Conversation

@robhogan

Copy link
Copy Markdown
Collaborator

Stacked on #1944.

Summary

#1944 gives FileSystem.lookup an Observations record to write what it looked at into. A path found goes in existence, which is right for the resolver asking "is there a file here?", but not for a caller that goes on to use what the file holds - that result also changes when the file is modified, which is what content means.

This adds opts.observeContent to lookup. When it's set, a file found is recorded in content instead. content is invalidated by everything existence is, so the path belongs in only one of them. A directory found, or a missing path, is still recorded in existence, and traversed symlinks are recorded in content as before.

The plugin-facing lookup given to file map plugins now takes observations too, and always sets it. That lookup exists to hand back plugin data, and plugin data is derived from what the file holds, so reading it is a content read.

The motivation is package.json. Metro reads those with fs outside the file map, and has no way to turn the absolute path it has into a canonical one to record. With this, plus lazy plugin data (#1950), a plugin can hold parsed package.json contents, and the lookup that fetches them records the read - which closes the last gap in what a resolution observes of the file map for a package.json. It's equally how a tsconfig.json would be read.

Nothing passes observations to either yet, so there's no behaviour change.

Test plan

yarn jest packages/metro-file-map packages/metro/src/node-haste packages/metro/src/DeltaBundler
yarn flow check
yarn typecheck-ts
yarn verify-api-snapshots
  • TreeFS-test.js: with observeContent, a file found is recorded in content and not existence, a file found through a symlink records its real path alongside the link, and a directory found or a missing path still goes in existence.
  • index-test.js: a plugin's lookup records a file as content, and a directory and a missing path as existence, in canonical form.

Changelog: Internal

Stacked on #1944.

## Summary
#1944 gives `FileSystem.lookup` an `Observations` record to write what it looked at into. A path found goes in `existence`, which is right for the resolver asking "is there a file here?", but not for a caller that goes on to use what the file holds - that result also changes when the file is modified, which is what `content` means.

This adds `opts.observeContent` to `lookup`. When it's set, a file found is recorded in `content` instead. `content` is invalidated by everything `existence` is, so the path belongs in only one of them. A directory found, or a missing path, is still recorded in `existence`, and traversed symlinks are recorded in `content` as before.

The plugin-facing `lookup` given to file map plugins now takes observations too, and always sets it. That lookup exists to hand back plugin data, and plugin data is derived from what the file holds, so reading it is a content read.

The motivation is `package.json`. Metro reads those with `fs` outside the file map, and has no way to turn the absolute path it has into a canonical one to record. With this, plus lazy plugin data (#1950), a plugin can hold parsed `package.json` contents, and the lookup that fetches them records the read - which closes the last gap in what a resolution observes of the file map for a `package.json`. It's equally how a `tsconfig.json` would be read.

Nothing passes observations to either yet, so there's no behaviour change.

## Test plan
```
yarn jest packages/metro-file-map packages/metro/src/node-haste packages/metro/src/DeltaBundler
yarn flow check
yarn typecheck-ts
yarn verify-api-snapshots
```
 - `TreeFS-test.js`: with `observeContent`, a file found is recorded in `content` and not `existence`, a file found through a symlink records its real path alongside the link, and a directory found or a missing path still goes in `existence`.
 - `index-test.js`: a plugin's `lookup` records a file as `content`, and a directory and a missing path as `existence`, in canonical form.

Changelog: Internal
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant