New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parcel plugin dev dep cache invalidation and hot reloading #5802
Conversation
This pull request has been linked to 2 tasks:
|
Benchmark ResultsKitchen Sink ✅
Timings
Cold Bundles
Cached Bundles
React HackerNews ✅
Timings
Cold Bundles
Cached Bundles
AtlasKit Editor ✅
Timings
Cold Bundles
Cached Bundles
Three.js ✅
Timings
Cold BundlesNo bundle changes detected. Cached Bundles
|
cb120dc
to
caeb12c
Compare
…validation # Conflicts: # yarn.lock
This doesn't introduce any issues in our app, so I'm on board with merging it. Though it would probably benefit from a technical review from @padmaia 😅 |
config.shouldReload(); | ||
contents.__contains_functions = true; | ||
|
||
// Also add the config as a dev dependency so we attempt to reload in watch mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't config.getConfig
do this for JS configs? loadConfig
in utils does checks for endsWith(".js")
anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, will do in a follow up pr.
T-377 T-383
This tracks dev dependencies (e.g. parcel plugins) in the request graph so that we invalidate when they are updated. There are dev_dep_request nodes in the graph which are connected to all of the files that the plugins include via require (tracked by the NodePackageManager). They also store a hash of all of these files. When a file changes, it invalidates the dev_dep_request, which in turns invalidates the asset_request. When the asset request is re-run, all of the valid dev_dep_requests are sent to the worker with their hash. This way we avoid recomputing the hash on each run, except if the dev dep is invalid.
The dev_dep_request nodes are shared between multiple asset_requests. This reduces the number of edges in the graph because only one edge is needed from asset_request to dev_dep_request rather than an edge to each individual file. It is possible, however, for multiple dev_dep_requests for the same plugin to exist, for example, due to conditional requires. A plugin may require different dependencies depending on the asset (e.g. parcel uses lazy requires that only load a module once it is used). The dependencies are recomputed for each request (though individual file hashes are cached during builds), and a new node will be created for each unique hash.
Aside from enabling cache invalidation for plugins (supporting manual editing of node_modules for debugging, patch-package, local plugins, etc.), this also enables HMR for parcel plugins and their dependencies. Since we already watch all dependencies and trigger a rebuild, we just need to clear the node require cache for that plugin and pretty much get HMR for free. This lets you work on a Parcel plugin or other dev dependency and see the results immediately without restarting the process. 😄
Parcel.Plugin.HMR.mov