Webpack doesn't emit scss import changes when using the cache

[abdelbk]

I have an scss file that looks like this:

#app.scss

@import 'file1'

When modifying the file1.scss, the changes are not emitted. However, if I change app.scss, it works fine.

My webpack.config.js looks like this:

module.exports = {
    module: {
      rules: [
        {
          test: /\.s?css$/,
          use: ExtractTextPlugin.extract({
            fallback: 'style-loader',
            use: 'happypack/loader?id=css'
          })
        }
      ]
    },
    
    plugins: [
      new ExtractTextPlugin({
        filename: cssOutputTemplate
      }),

      new HappyPack({
        id: 'css',
        loaders: ['css-loader', 'sass-loader', 'import-glob-loader'],
        threadPool: happyThreadPool
      })
    ]
 }

I believe there are some issues with nested imports, but I can't find a workaround. I don't want to disable HappyPack on sass files because there are a lot of them.

Any ideas ?

[amireh]

Not at the moment. I've been hearing similar reports surfacing after webpack2 but with different loaders so it looks like we need to look into this.

You can turn off the cache for now. Or does that not help either?

[abdelbk]

That bug persists even when the cache is turned off. We decided to not use Webpack after all. Webpack 2 doesn't seem that stable with all the loaders inconsistencies and lacks a robust caching system (like Rails' Asset Pipeline) which makes working on large applications really frustrating.
Thank you for the amazing work.

[amireh]

FWIW, you're probably better off with either of the following approaches:

• not to use ExtractText in development builds, only in production ones
• not to use webpack for anything that is not JS. This is what we do at work, we still use the sass binary for compiling scss and it's just fine really.

[RavenHursT]

The bug goes away for us when we turn the cache off for scss and css.. But it's definitely not picking up changes in imported scripts when the cache is turned on.

FWIW: We're even using a md5File.sync from md5-file as a custom cacheSignatureGenerator and it's still not picking up changes.

[amireh]

In the light of the change in v4 that drops caching from happypack, this ticket is no longer applicable so I'll be closing it. Please feel free to re-open if the issue persists (i.e. it's not related to caching.)

[RavenHursT]

@amireh caching has been removed from happypack? Do you have a link to any discussion as to why? Very sad to hear this :-(

[amireh]

There has been no discussion really - I just don't have the capacity to maintain it. The main concern of this library is to utilize multiple processes in the application of loaders, and it's good at doing that. Caching wasn't my intent but seeing how it was an "easy win", it was introduced.

However, the feature was never complete since there was no support for caching non-file system side-effects (like calls to emitWarning and emitError as could be done by linting loaders like ts-loader and eslint-loader). And working within a large team, I've come to shy away from all forms of caching since it requires people to know about the build pipeline (e.g. to rm .happypack/ when we introduce cache breaking changes that couldn't be identified by the plugin) and I want the process to be transparent to colleagues.

Having said that, I was hoping that someone else would take the lead in developing a proper caching layer for webpack, and thankfully that is being realized by projects like the hard-source plugin and the new cache-loader. Hopefully in time we can use those solutions in place of what happypack used to provide, and leave happypack to do what it set out to do.

I hope that answers it!

[RavenHursT]

Cool.. thanks for the explaination @amireh ... just sucks.. just last month I did a bunch of work to make CircleCi backup and restore happypack cache files for each build in jFrog's Artifactory..

Throw-away work stinks :-(

[amireh]

Maybe look into one of the resources I mentioned? It shouldn't be too hard to port.

I'd be interested to hear of your efforts because eventually I was going to do something like that for CI builds.

[RavenHursT]

Was basically a branch-named, versioned tar.gz that I packed up after each build, and then pulled back down before the next build on a given branch.. wasn't all too complicated of a concept.. just a pain given I had to do it all in bash :-(

[amireh]

If i remember correctly, the hard-source plugin can write the artifacts to disk so in theory you should be able to use it for warm compilations. At least that's what I was planning to do.