-
-
Notifications
You must be signed in to change notification settings - Fork 601
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: the auto
option for inline module syntax
#1274
Conversation
], | ||
Array [ | ||
"button.modules.css!=!./index-loader-syntax-sass.css", | ||
".iuzmhXWrT3_Z-zKS-rMGM { |
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.
Now they are CSS moduled
Codecov Report
@@ Coverage Diff @@
## master #1274 +/- ##
=======================================
Coverage 99.46% 99.46%
=======================================
Files 11 11
Lines 752 753 +1
Branches 256 258 +2
=======================================
+ Hits 748 749 +1
Misses 4 4
Continue to review full report at Codecov.
|
const { resourcePath } = loaderContext; | ||
const resourcePath = | ||
// eslint-disable-next-line no-underscore-dangle | ||
loaderContext._module.matchResource || loaderContext.resourcePath; |
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.
woohoo! should this also be the logic for local ident generation?
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.
Yep, you are right, otherwise we will get the same class names.
After fix local ident generation should we merge it and release? All is fixed?
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 so, seems like this covers it all. hard to know for sure until i try it out on a code base. Thanks again for helping me out here
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.
Yep, here interesting case, when we have:
import three from './button.module.scss!=!./base64-loader?LmZvbyB7IGNvbG9yOiByZWQ7IH0=!./simple.js';
import four from './other.module.scss!=!./base64-loader?LmZvbyB7IGNvbG9yOiByZWQ7IH0=!./simple.js';
We run the loader only once, why? Because ES modules executed only once. So I don't think here bug. But we can solve it using:
// i.e. adding `?` with different values
import three from './button.module.scss!=!./base64-loader?LmZvbyB7IGNvbG9yOiByZWQ7IH0=!./simple.js?foo=bar';
import four from './other.module.scss!=!./base64-loader?LmZvbyB7IGNvbG9yOiByZWQ7IH0=!./simple.js?foo=baz';
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.
ah interesting, so the query param acts like a cache buster. That solution seems fine to me
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.
yeah in my case it'd be easy to use a stable identifier here. This wouldn't solve the className hash generation issue tho right? I'm guessing you discovered this writing a test for that?
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.
Solved, please check code
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.
arg, i'm trying this out now and _module.matchResource
is null locally. Going to debug a bit to see why will report back
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.
If you don't have matchResource
in request, it will be nullish
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.
yeah this is for requests with it in it. For some reason i am seeing the module get created twice, one with the matchResource and one without, the one without is what makes it to the css-loader. It maybe has to do with ESM, still trying to figure it out
Array [ | ||
"other.module.scss!=!./base64-loader/index.js?[ident]!./simple.js?foo=baz", | ||
"._1KqQu-H04lA8NLg4-NKnDf { | ||
color: red; |
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.
You can see here: hash for classes are different
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.
But note: you should use different matchResource
, otherwise hash will be same
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.
perfect!
LGTM |
This PR contains a:
Motivation / Use-Case
fixes #1273
Breaking Changes
No
Additional Info
/cc @jquense fixed, please look