question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

cache of cache-loader causes problems with worker-loader

See original GitHub issue

Version

3.0.0-rc.5

Node and OS info

node: 8.11.1, npm: 6.1.0, OS: Debian 9

Steps to reproduce

I am using webpack worker-loader for web-workers. My vue.config looks like this

module.exports = {
  parallel: false,
  baseUrl: '/',
  configureWebpack: {
    /**
     * Setting the global object is necessary to make the loading of web-workers work. Otherwise, window is referenced
     * in the produced bundle, which is not accessable from a worker context. This seems to be a webpack 4 bug
     * https://github.com/webpack/webpack/issues/6642
     * https://github.com/webpack/webpack/issues/6629
     */
    output: {
      globalObject: 'self',
    },
    module: {
      rules: [
        {
          test: /\.worker\.js$/,
          use: [{ loader: 'worker-loader' }, { loader: 'babel-loader' }],
        },
        {
          test: /\.worker\.ts$/,
          use: [{ loader: 'worker-loader' }, { loader: 'babel-loader' }, { loader: 'ts-loader' }],
        },
      ],
    },
  },
}

What is expected?

Worker-loader should generate bundle files ([hash].worker.js) which should be loaded on request.

What is actually happening?

When <src>/node_modules/.cache is emptied everything works as expected.

If webpack-dev-server is started again via vue-cli-service serve The server doesn’t seem to have the requested worker script and serves index.html instead.

This is probably the intended behaviour by historyApiFallback of webpack-dev-server.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:3
  • Comments:9 (2 by maintainers)

github_iconTop GitHub Comments

38reactions
yyx990803commented, Aug 3, 2018

Note with rules added like this, both your loaders AND the internal loaders configured for *.js will be applied to *.worker.js files, which is certainly problematic. You may want to use chainWebpack to add *.worker.js files to the exclude list of the built-in js rule:

chainWebpack: config => {
  config.module.rule('js').exclude.add(/\.worker\.js$/)
}
2reactions
Janekdererstecommented, Aug 6, 2018

Thanks a lot @yyx990803. Excluding worker files from default loaders solved my problem.

Read more comments on GitHub >

github_iconTop Results From Across the Web

worker-loader - webpack - JS.ORG
webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable...
Read more >
worker-loader - webpack
npm i -D worker-loader. Usage. ##. App.js import Worker from 'worker-loader! ... which will be replaced with a content dependent hash for caching...
Read more >
Introduction to Guava CacheLoader | Baeldung
A short introduction to Guava's CacheLoader and its usage. ... Another common problem with caching is refreshing the cache.
Read more >
Caching - webpack
This guide focuses on the configuration needed to ensure files produced by webpack compilation can remain cached unless their contents has changed.
Read more >
thread-loader
thread-loader + cache-loader. ... First of all the quirky configuration required makes your webpack config rather less ... worker loader module for webpack....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found