Conversation
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
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.
Stacked on #1944.
Summary
#1944 gives
FileSystem.lookupanObservationsrecord to write what it looked at into. A path found goes inexistence, 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 whatcontentmeans.This adds
opts.observeContenttolookup. When it's set, a file found is recorded incontentinstead.contentis invalidated by everythingexistenceis, so the path belongs in only one of them. A directory found, or a missing path, is still recorded inexistence, and traversed symlinks are recorded incontentas before.The plugin-facing
lookupgiven 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 withfsoutside 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 parsedpackage.jsoncontents, and the lookup that fetches them records the read - which closes the last gap in what a resolution observes of the file map for apackage.json. It's equally how atsconfig.jsonwould be read.Nothing passes observations to either yet, so there's no behaviour change.
Test plan
TreeFS-test.js: withobserveContent, a file found is recorded incontentand notexistence, a file found through a symlink records its real path alongside the link, and a directory found or a missing path still goes inexistence.index-test.js: a plugin'slookuprecords a file ascontent, and a directory and a missing path asexistence, in canonical form.Changelog: Internal