-
-
Notifications
You must be signed in to change notification settings - Fork 608
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
Return the [folder] template #1371
Comments
Make sense, let's return this, you can send a PR, it should not hard |
inoyakaigor
added a commit
to inoyakaigor/css-loader
that referenced
this issue
Sep 14, 2021
6 tasks
Done: PR #1372 |
inoyakaigor
added a commit
to inoyakaigor/css-loader
that referenced
this issue
Sep 15, 2021
return code accidentally removed Closes webpack-contrib#1371
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Proposal
For context: an application written in React with this structure (simplified):
src/ComponentName/index.jsx
,src/ComponentName/index.css
.I'm talking about dev mode.
In PR #1333,
[folder]
and[emoji]
templates were removed. I agree that [emoji] should have been removed because naming css classes with emoji only makes sense for pet projects just for fun.But you can't say that about removing [folder] and that's why
Feature Use Case
Usabilty
In my projects I use the [folder]-[local] template and it gives this result:
This approach to css class naming allows you to immediately see the structure of application components without having to constantly switch between React devtools and the Elements tab to understand which React component the
Why not [path] or [path][name]__[local] as the docs say?
[path]

[path][name]__[local]

In the screenshots, you can see that the src-components- pattern is repeated. It doesn't make any sense (as a developer I already know that components are in src/components and all style files are named index.css), but it just creates visual noise that prevents you from understanding the components structure and css classnames.
Why not getLocalIdent()?
Using getLocalIdent() may solve this problem. Since developers have different levels of experience, this approach can cause both build errors and performance degradation due to poorly written code. Therefore, this should only be used if the developer really knows what he is doing.
Since deleted code is simple, does not perform heavy calculations and does not require constant attention in terms of bug fixes, possible vulnerabilities or any refactoring, its return will not degrade the developer's experience in any way and will not lead to degradation of css-loader and webpack performance.
@alexander-akait on Twitter told me that this template was removed because it wasn't used much. I think the reason is that most developers simply copied the recommended settings from the documentation (which is generally a good thing) due to lack of awareness or interest. They didn't try to figure out what features they had and what benefits it could give them, not because no one needed the template.
Please paste the results of
npx webpack-cli info
here, and mention other relevant informationThe text was updated successfully, but these errors were encountered: