imports aren't processed by webpack

[gitnik]

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 and vendor.js file which basically contains all external dependencies (in my case only node modules). This is done by utilizing the CommonChunksPlugin like so:

plugins: [
    new webpack.optimize.CommonsChunkPlugin({
        name: 'vendor',
        filename: 'vendor.js',
        minChunks: function (module, count) {
            return module.resource && module.resource.indexOf(appDir) === -1;
        }
    })
 ]

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? 😄

[gitnik]

Sooo any news on this?

[jsg2021]

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.
CSS references external sources... the css/style loader runs those through webpack loaders.

[gitnik]

Ok that's what I thought. Then I will probably have to move my includes from my SCSS into my JS

[jhnns]

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.scss

All the imports are done inside the main.scss.

Pros:

• No code duplication if done right
• You have complete control about the order how things are initialized

Cons:

• Can't be separated into vendor chunks or similiar
• No incremental rebuilds because the whole stylesheet needs to be rebuild just for a single change

2. Have on main.scss and on vendor.scss

Similiar to #1 but with manually separating vendor stuff from your application stuff.

Pros:

• Two different chunks that can be cached separately
• You have still complete control about the order how things are initialized

Cons:

• Rebuilds are a bit faster, but still take some time
• Referencing/importing stuff from vendor styles into main.scss may duplicate code

3. Truely modular styles

Every 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:

• Fast rebuilds
• Styles are loaded "on demand"

Cons:

• The initial build takes much longer because each component spawns its own Sass process
• Potential code duplication (which is usually not problem when using gzip)
• Using the ExtractTextWebpackPlugin is counterproductive

[jedwards1211]

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)

[jhnns]

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?

[jedwards1211]

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.

[jhnns]

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.

[jedwards1211]

Ahhhh, gotcha.