developit / developit/workerize-loader
[path] replacer token passed to workerize-loader has stopped working in Webpack 5
- Ngôn ngữ chính
- JavaScript
- Star
- 2.3k
- Fork
- 85
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Mô tả
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
```js
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:
```js
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:
```js
new InjectOptionsPlugin({
loaders : {
"workerize-loader" : {
name : dev ? "[path][name]" : "[path][name].[contenthash]"
}
}
})
```
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Đánh giá
Issue này chưa được đánh giá.