-
-
Notifications
You must be signed in to change notification settings - Fork 428
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
imports aren't processed by webpack #164
Comments
Sooo any news on this? |
scss imports are processed by libsass, by design. importing css from an alternate language does pop you out to webpack. you can also use module import syntax... I forget what that is, but it makes sass-loader look for the sass file in a node_module. Basically, sass compiles to CSS. |
Ok that's what I thought. Then I will probably have to move my includes from my SCSS into my JS |
It's not a bug, @jsg2021 is mostly right. Though webpack is doing the file resolving, the output is kind of monolithic. That means that once Sass is done, webpack just receives one big blob of CSS without any trace of modules. So, there are basically three ways to structure your styles: 1. Have one monolithic main.scssAll the imports are done inside the Pros:
Cons:
2. Have on main.scss and on vendor.scssSimiliar to #1 but with manually separating vendor stuff from your application stuff. Pros:
Cons:
3. Truely modular stylesEvery component has its own, independent Sass build. In order to avoid code duplication, you need to separate your Sass modules between modules which produce CSS code and modules which just provide variables and functionality like mixins. But imho that's best practice anyway. Pros:
Cons:
|
I wonder if it would be possible/faster for sass-loader to concat all sass modules being compiled/recompiled together, then compile them with a single Sass process, and then somehow split the CSS back apart? (e.g. by inserting special comments for module boundaries) |
That sounds pretty impossible to me. It's also not clear what problem you're trying to solve. Why should it be faster? What is actually slow? |
I don't really know how slow it is (I know some of my big Webpack projects build slowly but I'm not sure if Sass has anything to do with it). I was just thinking about how you said above that "The initial build takes much longer because each component spawns its own Sass process." If multiple Sass processes cause slowness, using a single Sass process could theoretically improve that. |
Yep, but when using a single Sass process, modules would influence each other, yielding to unexpected output. |
Ahhhh, gotcha. |
I am not sure if this a bug, I am misusing something or it's simply not possible. So bear with me as I try to explain my issue.
I am currently splitting up my js/scss/fonts etc into two different files, a
bundle.js
file that contains only MY code andvendor.js
file which basically contains all external dependencies (in my case only node modules). This is done by utilizing theCommonChunksPlugin
like so:This works like a charm for all JS, but unfortunately not for imported scss files.
It seems that files imported inside my scss are not run trough webpack's usual workflow and therefore never reach the plugin, but rather are just "copy-pasted" into my main scss file. This also becomes clear when logging
module.resource
to the console inside the plugin config; there is no bootstrap file being processed, but rather a a main scss file (which sits inside my app dir) that has the bootstrap scss already included. This pretty much defeats the purpose of having a vendor file for me 😿Is this a bug or a feature? 😄
The text was updated successfully, but these errors were encountered: