When dealing with components (such as React components) it is useful to have the styling closely coupled to the component itself. It is not uncommon to have the CSS for the component within the component directory itself.

TL;TD

the source files are available online at https://github.com/planetflash/sharing_sass_resources

the demo site can be viewed at https://planetflash.github.io/sharing_sass_resources/

A typical component folder structure for my React apps

We will have variables (such as colors) and mixins (such as breakpoints) that we may wish to use in each of these components, but currently they are not available to use. We can define these globally and import them into each .scss file:

// button.scss

@import "../path/to/sass/variables.scss";

@import "../path/to/sass/mixins.scss"; .btn {

...

background: map-get($colors, primary);

...

}

But this is tiresome and prone to error if we forget to do it. We also have to instruct any member of the development team to remember to do it too. If we ever decided to split the mixins.scss further (perhaps into mixins.scss and mediaQueries.scss ) we must then go back through our files and adding the new import.

Lets get some automation

Using webpack and sass-resources-loader we can automate this process and have our mixins, variables etc. available to us in any .scss file. First we create our utils.scss file, which will contain all of the Sass we wish to have available to us. It’s important to note — do not include any files here which will have actual css output, otherwise our bundle file size will grow rapidly as the output will be in every file.

// utils.scss

@import variables.scss

@import mediaQueries.scss

@import mixins.scss

Then we use sass-resources-loader in our webpack config to automatically inject this into the top of any .scss file in our project.

// webpack.config.js

...

{

test: /\.scss$/,

use: [

{

loader: "style-loader",

}, {

loader: "css-loader",

}, {

loader: "sass-loader",

}, {

loader: "sass-resources-loader",

options: {

resources: require(path.join(process.cwd(), "src/sass/utils.scss")),

}

}

],

}

...

However, sass-resources-loader recommends avoiding using “SASS @import rules inside resources files as it slows down incremental builds”. You can pass an array of resources to the loader, but I prefer to keep my resources file in my sass folder. We can get around this issue using a utils.js file rather than a utils.scss file and importing the resources like so:

// utils.js

const path = require("path"); const resources = [

"_ceaser.scss",

"_variables.scss",

"_mediaQueries.scss",

"_mixins.scss"

]; module.exports = resources.map(file => path.resolve(__dirname, file));

Our webpack config is simply amended to include the .js file instead of the .scss file.

// webopack.config.js

...

loader: "sass-resources-loader",

options: {

resources: require(path.join(process.cwd(), "src/sass/utils.js")),

}

...

Our resources are now available to us in every .scss file and we have a neat and tidy folder structure.

I’m Paul Thomas and I’m a Lead Developer at Immersive Labs in Bristol, UK.