-
Notifications
You must be signed in to change notification settings - Fork 0
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
Exclude node_modules from importing css modules #1
Conversation
I just realized I did this wrong, one more commit incoming. |
I'm EDIT not /EDIT sure I follow what's going on here. You have two loaders that are similar (the second being the only one to load the |
I've restored postcss-next and remove the modules setting. |
@@ -107,14 +136,21 @@ export function webpackConfig(env) { | |||
|
|||
if (isProd) { | |||
// fix loaders for prod | |||
const [, cssLoader] = loaders; | |||
const [, thirdPartyCssLoader, cssLoader] = loaders; |
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 don't follow all this, but where is the third party one split from the regular loader?
I'm not a big fan of this webpack config because it is hard to follow. The initial commits to this branch added in a separate loader for CSS files that come from the node_modules directory (so that |
I think the general opinion is that any webpack config is confusing, so
let's bury as much of it as possible. There's a very complicated dance
between webpack, babel, react, css and etc. I was just confused how a
single commit to that array destructuring worked without changing the
source of the array...
…On Tue, May 23, 2017 at 10:22 AM, Jeffrey Smith ***@***.***> wrote:
I'm not a big fan of this webpack config because it *is* hard to follow.
The initial commits to this branch added in a separate loader for CSS files
that come from the node_modules directory (so that modules:true wasn't
set). Because of that, I needed to wrap it with the ExtractTextPlugin the
same way that the original CSS loader did. It would be preferable to have
something like webpack.config.production.js and webpack.development.js. The
redundancy would be worth it IMO.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAOsLB9tsa3S3FTnf6BqPDydUsqjBDWxks5r8uuygaJpZM4Nfa9Z>
.
|
@djMax What do I have to do to get this approved? |
@jasisk is the one to press the button on this one. |
Will review first thing in the am. |
In the consumer-web project, we're attempting to import a CSS file from node_modules, but the default behavior is to import the file using CSS Modules, which effectively namespaces class names. We had to override the loaders in the import statement and tell ESLint to ignore the behavior. We should assume that a CSS file coming from node_modules should not be namespaced and should be globally applicable.