-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Drop per-pipeline transformation cache #9459
Conversation
AFAICT, parcel/packages/core/core/src/types.js Line 172 in 8ba5523
|
Does this effect the caching impact of |
No. JS files are still harder to cache because they can produce non-deterministic results, and we have to take into account all of the dependencies they import/require etc. |
* upstream/v2: (22 commits) Add source map support to the inline-require optimizer (#9511) [Web Extension] Add content script world property to manifest schema validation (#9510) feat: add getCurrentPackageManager (#9505) Default Bundler Contributor Notes (#9488) rename parentAsset to root for msb config and remove unstable (#9486) Macro errors -> v2 (#9501) Statically evaluate constants referenced by macros (#9487) Multiple css bundles in Entry bundle groups issue (#9023) Fix macro issues (#9485) Bump follow-redirects from 1.14.7 to 1.15.4 (#9475) Revert more CI changes to centos job (#9472) Use lightningcss to implement CSS packager (#8492) Fixup CI again (#9471) Clippy and use napi's Either3 (#9047) Upgrade to eslint 8 (#8580) Add support for JS macros (#9299) Fixup REPL CI (#9467) Drop per-pipeline transformation cache (#9459) Upgrade some CI actions (#9466) REPL (#9365) ...
This was extracted from the db2 branch. As discussed in previous core team meetings, this removes the per-pipeline transformation cache. This is only hit when:
Other cases are already handled by the request graph which won't even run an asset request that isn't invalidated.
Given the limited cases where it would be hit, the transformation cache results in a lot of complexity and issues. It is difficult if almost impossible to compute the cache keys for transformations ahead of time. You need to know all of the files, configs, dev dependencies, options, environment variables, etc. that will be used when doing a build for an asset, all of which require the request graph to know, so the transformation cache couldn't even be used standalone. In addition there were some bugs because it's hard to associate each of these to the correct plugins, especially dev dependencies which are be loaded on demand. For these reasons, we decided to remove the transformation cache and just rely on the request graph to know when to rebuild.
One other benefit of this change is that each asset only has one key in the cache now, whereas previously the cache would grow unbounded as changes were made.
In the future perhaps we can find other ways to address the above cases if we find this change results in widespread performance regressions.