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.

Getting error in web workers

See original GitHub issue

I’m getting error when using with web workers: Uncaught ReferenceError: $RefreshReg$ is not defined

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:12
  • Comments:30 (15 by maintainers)

github_iconTop GitHub Comments

10reactions
pmmmwhcommented, Aug 12, 2020

@blacksteed232 @GuskiS

I have some workarounds.

Sloppy

  • In the entry of your Worker, add the following two lines:

    self.$RefreshReg$ = () => {};
    self.$RefreshSig$$ = () => () => {};
    
  • This is basically a “polyfill” for helpers expected by react-refresh/babel

Simple

  • You don’t have to mess with configurations
  • Ensure all exports in the whole code path does not contain anything in PascalCase, which will make the Babel plugin do nothing when it hits your files
  • In general, the PascalCase naming scheme should be reserved for React components only, and I assume there wouldn’t exist any React components within a Web Worker
  • Slight issue is when you have dependencies with that naming scheme, but most setups bypass node_modules from Babel anyways

Robust

  • Similar to what @blacksteed232 attempted, but with Webpack’s oneOf rule

  • Alter the Webpack module rules (the section for JS-related files) as follows:

    {
      rules: [
        // JS-related rules only
        {
          oneOf: [
            {
              test: /\.[jt]s$/,
              include: '<Your worker files here>',
              exclude: /node_modules/,
              use: {
                loader: 'babel-loader',
                options: {
                  // Your Babel config here
                },
              },
            },
            {
              test: /\.[jt]sx?$/,
              include: '<Your files here>',
              exclude: ['<Your worker files here>', /node_modules/],
              use: {
                loader: 'babel-loader',
                options: {
                  // Your Babel config here
                },
              },
            },
          ],
        },
        // Any other rules, such as CSS
        {
          test: /\.css$/,
          use: ['style-loader', 'css-loader'],
        },
      ],
    }
    

Edit:

I also would suggest to not run ReactRefreshPlugin through WorkerPlugin - messing with module templates in child compilers for a different realm does not end well from my testing while figuring out the two solutions above. It COULD be made to work, but I currently don’t see a good path towards that goal.

I do understand that it is a bit of work to add this configuration, but I also hope that people can understand that react-refresh and this plugin weren’t designed to be used “standalone” or in non-React related code paths. For the case of Web Workers, in my honest opinion, I think they should be compiled from the start separately (in terms of TypeScript/Babel transpilation) - import/exports are not available natively, and the global object is different.

Hopefully this provided some insight and hopefully the workarounds above have solved your problems!

2reactions
pmmmwhcommented, Aug 12, 2020

Happy that the resolutions worked for both of you!

But that got me thinking, could it be possible that I’m somehow importing that code as worker and directly? For example, that file contains class, in my code it is only used as worker(new Worker("./myworker.worker.ts")), but in few typing files I use it as type definition to see what methods are being exposed.

Could something in bundling process mess it up? I haven’t analyzed bundle output in a while, will give it a try later.

If you are on TypeScript 3.8+, I highly suggest checking out the import type syntax, this option for TypeScript and this option for Babel’s TypeScript transpilation. Type imports ensures that no side effects will be ran from the imported module, and they will be erased completely after bundling.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Worker: error event - Web APIs - MDN Web Docs
The error event of the Worker interface fires when an error occurs in the worker. Syntax. Use the event name in methods like...
Read more >
Web workers: errors and debugging - Human Who Codes
The web workers specification indicates that an error event should be fired when a JavaScript error occurs in a worker.
Read more >
How to handle errors in HTML5 Web Workers? - Tutorialspoint
In this article, we will discuss about how to solve such issues. The solution is Web workers. But what is a web worker?...
Read more >
javascript - How to bubble a web worker error in a promise via ...
I'm dealing with a web worker that needs to report back if an error has occured. Normally, I can use worker.onerror to listen...
Read more >
Logging Errors in Web Workers - TrackJS
Enter our hero, TrackJS. By adding the TrackJS agent to your web workers, you'll get visibility into all types of errors from your...
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