CODEWITHSUNDEEP
webpacksass
johnnycopes
johnnycopes

Reputation: 424

SCSS partials (@import) vs. Webpack file import?

I'm building a simple app and am setting up my own Webpack configuration to better understand how it works. Currently, I have one main.scss file (where I'm writing all my styles) which I'm importing into my index.js file (which is the entry point I've set for Webpack). So far, so good.

Now I want to split my SCSS into separate, smaller files (normalize, variables, mixins, etc.) Before Webpack, what I'd do was make every file a SCSS partial and then import all of them into my main.scss file. But now that I'm using Webpack, I'm wondering if I should keep doing that or if I should import all of my SCSS files into Webpack instead and forgo partials entirely? Any clarification on the topic would be useful; I haven't found much online about the advantages of one approach over the other.

Upvotes: 3

Views: 3129

Answers (2)

Christian Santos
Christian Santos

Reputation: 5456

Here's a setup I've used in past React projects:

  • import main.scss from your index.js

  • In your main.scss use import-glob-loader to automate the process of importing new sass files -- it's easy to forget to add every new sass file to main.scss. Your main.scss would look something like:

main.scss

@import "src/normalize"
@import "src/components/**/*"

Webpack.config.js (Webpack 2+)

 rules: [
    {
        test: /\.scss/,
        enforce: "pre",
        loader: "import-glob-loader"
    },
    // ... other loaders
]

This will automatically bundle new sass files that you add to src. When using this setup it's important to minimize @imports in your sass files as this will increase the overall size of the generated CSS file. The exception is @importing files that only contain mixins and variables, as these imports do not add to the file size.

This setup makes the most sense when used with a framework like React, where you would have many sass files in many different directories (usually in the respective component's directory)

Upvotes: 3

KyTrol
KyTrol

Reputation: 388

I came across this situation in a small multi page application I was building. When I got to the point where I started splitting the css based on pages, let's say page-1.scss, page-2.scss, and page-3.scss, I wanted to create a common.bundle.css which contained css used on all pages.

At first, I had an @import '_base'; declaration at the top of each page-*.scss file. I assumed CommonsChunkPlugin would take into account these similar imports and extract them into common.bundle.css. But I found that _base.scss was still duplicated across each page-*.bundle.css. After importing each shared partial in the page's respective entry js file, CommonsChunkPlugin was able to correctly extract each shared partial into common.bundle.css.

It seemed as though using the SCSS @import imported all partials into one css file and then webpack treated that file as one dependency. Using webpack's import treated each partial as a dependency which CommonsChunkPlugin was able to act on.

So, for my one situation, importing through webpack was preferable to SCSS imports. Unfortunately, I do not have any relevant links on this particular situation, as this is all based on personal experience.

Upvotes: 1

Related Questions