Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[path] replacer token passed to workerize-loader has stopped working in Webpack 5

Open
#130 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript, webpack

Research direction

Reproduce the issue with workerize-loader under Webpack 5 using the bare loader URL and the [path][name].[contenthash] template described here. Trace how the loader handles its name option and compare [path] with the working [name] and [contenthash] tokens; done means worker output preserves source-relative paths without requiring external option injection.

Written by the indexing model from the issue text.

Description

Used to be the case with Webpack 4 that we could pass [path][name].[contenthash] as the name template for workerize-loader to use; and we'd get workers output into a folder structure mirroring their original source location.

This was nice for debugging purposes to easily identify workers, because the entry point file for esp. larger workers is usually some kind of index.js file. [path] means you don't need to inspect every separate worker named index.[hash].worker.js - and it prevented name collisions when you would generate names in development builds without hash fingerprints in them.

As of Webpack 5, that functionality appears to be broken. It resolves [name] and [contenthash] just fine, but doesn't know how to deal with [path].

I'm using a plugin to dynamically inject options into loaders to configure bare loader URLs such as

import worker from "workerize-loader!./path-to/worker"

centrally, and luckily I was able to extend the logic there to use the current compilation context and module context to compute a relative path, but yeah... this is not very ergonomic, easily understood or maintainable:

new InjectOptionsPlugin({
  loaders : {
    "workerize-loader" : ( module, compilation ) => {
      const context = path
        .relative( compilation.options.context, module.context );
        .replace( /\\/g, "/" );
        
      return {
        name : dev ? `${context}[name]` : "${context}[name].[contenthash]`
      };
    }
  }
})

compared to what it used to be:

new InjectOptionsPlugin({
  loaders : {
    "workerize-loader" : {
      name : dev ? "[path][name]" : "[path][name].[contenthash]"
    }
  }
})
Dominant language
JavaScript
Stars
2.3k
Forks
85
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from developit/workerize-loader

All issues in developit/workerize-loader

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.