-
-
Notifications
You must be signed in to change notification settings - Fork 383
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: allow consumers to access CssModule #703
Conversation
Hey, This PR fixes a subtle breaking change happened in the last release. I had an integration that was injecting CssModule instances to the compilation, and it assumed this plugin will take care of them. After the latest release it was impossible for me to get the CssModule class since it cannot be registered twice for serialization. This PR allows others to get access to the CssModule class within same webpack running version.
Codecov Report
@@ Coverage Diff @@
## master #703 +/- ##
==========================================
+ Coverage 89.58% 89.75% +0.17%
==========================================
Files 6 6
Lines 768 771 +3
Branches 232 235 +3
==========================================
+ Hits 688 692 +4
+ Misses 77 76 -1
Partials 3 3
Continue to review full report at Codecov.
|
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.
We need small test for this to avoid this problem in future + comments why we need to do it
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.
I think we need do the same for CssDependency
, so we need to remove shared
and use the same approach
I'm not sure what's going on with the lint. maybe related to new lines? |
Yep, need to run |
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.
I think we don't need shared
util anymore, just use plugin.getCssDependency(webpack)
in loader
true. I'm not sure about this error now it cannot happen.
|
|
also something with prettier is not working for me. |
But now it will always generate the CSSDependency class. I can add validation that it already requested once if needed |
Run |
Yep, I think it make sense |
first prettier is failed to execute for some unknown reason. (I can share the log if needed) |
Agree, we can use |
Sine I'm kind of working on blind. I will need to double check this. I will try to clone it later with correct NL config and try to run all the lints and tests locally. |
The lint error is just for the commit messages it can be solved with squash. The other tests I'm not sure about. It seems that it's also broken on master. |
the failing test looks to me like pure flakiness. from my perspective this PR is ready. |
Thanks |
Is this correct change? Shouldn't here I did hit issue of getting those recent release:
Tho this might be wrong configuration for SSR bundle compilation where I don't want to extract css anymore (because that happen in browser bundle compilation), but I do still have |
This loader doesn't have sense without the plugin |
Using extra loader on top reduce your bundling perf, so I recommend to remove it |
This PR contains a:
Motivation / Use-Case
Hey,
This PR fixes a subtle breaking change happened in the last release.
I had an integration that was injecting CssModule instances to the compilation, and it assumed this plugin will take care of them.
After the latest release it was impossible for me to get the CssModule class since it cannot be registered twice for serialization.
This PR allows others to get access to the CssModule class within same webpack running version.
Breaking Changes
none
Additional Info