-
Notifications
You must be signed in to change notification settings - Fork 636
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
experimentalImportBundleSupport: Retraverse parents of deleted async …
…dependencies Summary: Changelog: [Experimental] Correctly invalidates resolved async dependencies when their target files are deleted, by tracking inverse dependencies of entries in `importBundleNames` ( = async dependencies not necessarily tracked in the `dependencies` set). ## Problem Suppose we have the following two files ``` // /src/a.js import('b'); ``` ``` // /src/b.js export default 42; ``` described by the following dependency graph: ``` ┌───────────┐ import('b') ┌───────────┐ │ /src/a.js │ ─────────────▶ │ /src/b.js │ └───────────┘ └───────────┘ ``` Now suppose we delete `/src/b.js`: * If we delete it and immediately perform a build, we'd expect the resolver to throw an error. * If we recreate `b.js` in a different directory ( = move it) we'd expect the resolution to be updated. (For the sake of this example, assume we're using Haste resolution.) In short, this needs to work the way sync dependencies work: the inverse dependencies of a deleted node must be invalidated so that their dependencies are resolved anew in the next build. But under `experimentalImportBundleSupport: true`, `b.js` is not tracked as a node in the `dependencies` set, so the code in `DeltaCalculator` that is responsible for this does not apply. ## Solution Here, we create a `getModifiedModulesForDeletedPath` method on `Graph`, which: 1. Encapsulates what `DeltaCalculator` previously did by directly reading `dependencies`. 2. Also returns the inverse dependencies of async modules that may not exist in the `dependencies` set. (2) is achieved by tracking resolved async modules as nodes in a separate set (`importBundleNodes`). These nodes cannot have their own dependencies, so they can't introduce cycles and therefore don't need any new handling in terms of GC. We repurpose the existing logic that maintained `importBundleNames` and expose an `importBundleNames` getter for compatibility. NOTE: Ultimately, I'm planning to remove the `importBundleNames` kludge entirely and instead serialise the resolved paths of async dependencies inside each parent module's dependency array. The current diff directly enables that by preventing improper caching of the paths. (But as explained above, this improper caching is *already* a bug regardless.) Reviewed By: jacdebug Differential Revision: D40463613 fbshipit-source-id: 35c73b0ae8c50d742bd08386d0247fa1e337d6b0
- Loading branch information
1 parent
fb0020c
commit cb806d1
Showing
4 changed files
with
134 additions
and
55 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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