Traditionally, I've been a LESS supporter. The way it does mixins for example seems to me more intuitive. However, I noticed that my go-to framework (bootstrap) is now doing SASS-first and then LESS. So, one adapts... and the option in angular-cli makes things less painful. What was painful was to convert a bunch of LESS code to SCSS :/

Here are some findings relative to using SCSS in my application:

  • Webpack does it nicely via the sass-loader
  • You can use relative, absolute and ~ paths to refer to other resources. ~ does module resolution for e.g. FontAwesome.

I have the following topology:

  • src/app - contains component-specific SCSS files, as defined by angular-cli
  • src/public - contains common styles, fonts and other assets.

My resulting relevant definition in webpack is:

const rules = {
  //...
  componentStyles: {
    test: /\.scss$/,
    loaders: ['raw-loader', 'sass-loader'],
    include: path.resolve(__dirname, 'src/app')
  },
  sharedStyles: {
    test: /\.scss$/,
    loaders: ['raw-loader', 'sass-loader?sourceMap'],
    exclude: path.resolve(__dirname, 'src/app')
  }
  //...
}

Here is how I use it in the configuration:

const config = (module.exports = {})

config.module = {
  rules: [
    //...
    rules.componentStyles,
    rules.sharedStyles
  ]
}

Webpack also needs loaders to be configured:

config.plugins = [
  new LoaderOptionsPlugin({
    debug: false,
    minimize: false,
    options: {
      postcss: [autoprefixer({ browsers: ['last 3 versions'] })],
      resolve: {},
      sassLoader: {
        includePaths: ['src/public'],
        outputStyle: 'compressed',
        precision: 10,
        sourceComments: true
      }
    }
  })
  // new ForkCheckerPlugin()
]

Note: This is only a fragment of my webpack.config.js file.

From this point on, we'll need explicit webpack commands to be able to run the application properly...

HTH,