-
Notifications
You must be signed in to change notification settings - Fork 414
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
fix(webpack): replace file system cache with in-memory cache (fixes #878) #879
Conversation
Hi @malash, |
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.
Thanks @Anber for your great work! This PR is awesome and in-memory cache must provide better performance than file system cache.
I'v review the PR and leave some comments.
B.T.W. Do you have plan to cherry-pick this PR into Linaria v2, since it's still the stable branch in NPM ?
I didn't have, before you asked for :) I'll release it in v2 as well. |
What test can I use to detect linaria css files now that the .linaria-cache directory is not a test? PS) Would be nice to publicize breaking changes like this and migration paths. |
Figured it out for others looking: |
A better solution for double rebuilds is to add a watch ignore as tricking webpack into think css is a js file breaks a lot of assumptions other webpack tools will make - including the popular react-refresh |
@ntucker I did try I prefer inline matchResource because it is an officially recommended way to support CSS-in-JS in Webpack. However 3rd-party libraries have to take some efforts to support virtual files. |
@malash can you point me to the docs where they mention this usage with css-in-js? All I see is the warning: "It is not recommended to use this syntax in application code. Inline request syntax is intended to only be used by loader generated code. Not following this recommendation will make your code webpack-specific and non-standard." And even after diving it - it's unclear how to detect these properly so they aren't treated as JS files. Specifically the very popular react-refresh plugin doesn't seem to work with it #897 |
@ntucker This demo code is an example of CSS-in-JS. It use comment to contain the CSS source. As i understand in that sentence
|
This is the full moduleData of a css module created in this way (from console log in https://github.com/pmmmwh/react-refresh-webpack-plugin/blob/ebe885a1df2cd528645b7cc68dfc4fa59dde4d11/lib/utils/injectRefreshLoader.js) - while it's getting some of the correct loaders, it shows up as type: 'javascript/auto', which makes it impossible to distinguish from other js files
|
…ixes callstack#878) (callstack#879)" This reverts commit 5517cf7.
Motivation
Current implementations of webpack loaders use file system cache for storing evaluated css-files. It causes a few problems with URLs in CSS, with HMR and even with finding a root of a project (if Linaria is used in monorepo). At the same time, Rollup loader uses in-memory cache that works pretty good.
Summary
In #878 @malash suggested using
inline matchResource
in order to fix doubled reloads. It appeared, that with such a tool we can finally get rid of filesystem cache and migrate to in-memory cache, which seems to be much more problemless.