[Feature]: support speed-measure-webpack-plugin

[renzp94]

System Info

System:
OS: macOS 14.2.1
CPU: (8) arm64 Apple M1 Pro
Memory: 100.42 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
Yarn: 1.22.17 - /usr/local/bin/yarn
npm: 10.5.0 - ~/.nvm/versions/node/v20.12.2/bin/npm
pnpm: 9.0.6 - ~/.nvm/versions/node/v20.12.2/bin/pnpm
bun: 1.1.8 - ~/.bun/bin/bun
Watchman: 2024.01.22.00 - /opt/homebrew/bin/watchman
Browsers:
Chrome: 125.0.6422.113
Safari: 17.2.1

Details

ERROR: Error: × TypeError: Cannot read properties of undefined (reading 'tap')
│ at module.exports.tap (/Users/mr.r/Documents/xgamer/github/renzp94/rzpack/node_modules/.pnpm/[email protected]_webpack@5.91.0_@swc[email protected][email protected]_/node_modules/
│ speed-measure-webpack-plugin/utils.js:157:45)
│ at Object.fn (/Users/mr.r/Documents/xgamer/github/renzp94/rzpack/node_modules/.pnpm/[email protected]_webpack@5.91.0_@swc[email protected][email protected]_/node_modules/speed-
│ measure-webpack-plugin/index.js:256:7)
│ at SyncHook.callAsyncStageRange (/Users/mr.r/Documents/xgamer/github/renzp94/rzpack/node_modules/.pnpm/@rspack[email protected]/node_modules/@rspack/core/dist/lite-tapable/index.js:214:21)
│ at SyncHook.callStageRange (/Users/mr.r/Documents/xgamer/github/renzp94/rzpack/node_modules/.pnpm/@rspack[email protected]/node_modules/@rspack/core/dist/lite-tapable/index.js:232:14)
│ at QueriedHook.call (/Users/mr.r/Documents/xgamer/github/renzp94/rzpack/node_modules/.pnpm/@rspack[email protected]/node_modules/@rspack/core/dist/lite-tapable/index.js:193:26)
│ at /Users/mr.r/Documents/xgamer/github/renzp94/rzpack/node_modules/.pnpm/@rspack[email protected]/node_modules/@rspack/core/dist/Compiler.js:575:244
│ at last.function (/Users/mr.r/Documents/xgamer/github/renzp94/rzpack/node_modules/.pnpm/@rspack[email protected]/node_modules/@rspack/core/dist/Compiler.js:746:28)

Reproduce link

https://github.com/renzp94/rzpack

Reproduce Steps

For example:

• pnpm install
• pnpm run playground:build:time

[LingyuCoder]

Rspack does not support compilation.normalModuleLoader hook yet, which is used by speed-measure-webpack-plugin. Loader resolving is on the Rust side and it will affect performance significantly if port to JavaScript side. Some loaders are implemented by Rust so that they can not be measured by this plugin.

So you can try to follow rspack profiling guide to trace events of rspack. And also you can try to use rsdoctor for more detailed performance data analysis.

[renzp94]

Rspack does not support compilation.normalModuleLoader hook yet, which is used by speed-measure-webpack-plugin. Loader resolving is on the Rust side and it will affect performance significantly if port to JavaScript side. Some loaders are implemented by Rust so that they can not be measured by this plugin.

So you can try to follow rspack profiling guide to trace events of rspack. And also you can try to use rsdoctor for more detailed performance data analysis.

I developed a packaging tool using webpack: rzpack. Now I want to support rspack packaging. As a new feature, rsdoctor is supported, but I want to keep it consistent with the usage of webpack. Do you have any plans to support it?

[LingyuCoder]

Rspack does not support compilation.normalModuleLoader hook yet, which is used by speed-measure-webpack-plugin. Loader resolving is on the Rust side and it will affect performance significantly if port to JavaScript side. Some loaders are implemented by Rust so that they can not be measured by this plugin.
So you can try to follow rspack profiling guide to trace events of rspack. And also you can try to use rsdoctor for more detailed performance data analysis.

I used webpack to package a packaging tool: rzpack. Now I want to support rspack and make it as compatible as possible with previous features. Is there a plan to support it?

Rsdoctor can be used on webpack too.

The compilation.normalModuleLoader hook will be deprecated in webpack. You can see it here.

In webpack5 it will be replaced with NormalModule.getCompilationHooks(compilation).loader and this has been implemented in rspack but can not modify the loader context yet. Modifing loader context affects a lot and it is a hard job. Perhaps we will support it after 1.0 released

[renzp94]

Rspack does not support compilation.normalModuleLoader hook yet, which is used by speed-measure-webpack-plugin. Loader resolving is on the Rust side and it will affect performance significantly if port to JavaScript side. Some loaders are implemented by Rust so that they can not be measured by this plugin.
So you can try to follow rspack profiling guide to trace events of rspack. And also you can try to use rsdoctor for more detailed performance data analysis.

I used webpack to package a packaging tool: rzpack. Now I want to support rspack and make it as compatible as possible with previous features. Is there a plan to support it?

Rsdoctor can be used on webpack too.

The compilation.normalModuleLoader hook will be deprecated in webpack. You can see it here.

In webpack5 it will be replaced with NormalModule.getCompilationHooks(compilation).loader and this has been implemented in rspack but can not modify the loader context yet. Modifing loader context affects a lot and it is a hard job. Perhaps we will support it after 1.0 released

Thank you very much for the answer. I am looking forward to the release of 1.0.

[easy1090]

Rspack does not support compilation.normalModuleLoader hook yet, which is used by speed-measure-webpack-plugin. Loader resolving is on the Rust side and it will affect performance significantly if port to JavaScript side. Some loaders are implemented by Rust so that they can not be measured by this plugin.
So you can try to follow rspack profiling guide to trace events of rspack. And also you can try to use rsdoctor for more detailed performance data analysis.

I developed a packaging tool using webpack: rzpack. Now I want to support rspack packaging. As a new feature, rsdoctor is supported, but I want to keep it consistent with the usage of webpack. Do you have any plans to support it?

rsdoctor also supports webpack analysis. @renzp94

[renzp94]

Rspack does not support compilation.normalModuleLoader hook yet, which is used by speed-measure-webpack-plugin. Loader resolving is on the Rust side and it will affect performance significantly if port to JavaScript side. Some loaders are implemented by Rust so that they can not be measured by this plugin.
So you can try to follow rspack profiling guide to trace events of rspack. And also you can try to use rsdoctor for more detailed performance data analysis.

I developed a packaging tool using webpack: rzpack. Now I want to support rspack packaging. As a new feature, rsdoctor is supported, but I want to keep it consistent with the usage of webpack. Do you have any plans to support it?

rsdoctor also supports webpack analysis. @renzp94

I know, but I want to be compatible with speed-measure-webpack-plugin.@easy1090

Rspack does not support compilation.normalModuleLoader hook yet, which is used by speed-measure-webpack-plugin. Loader resolving is on the Rust side and it will affect performance significantly if port to JavaScript side. Some loaders are implemented by Rust so that they can not be measured by this plugin.
So you can try to follow rspack profiling guide to trace events of rspack. And also you can try to use rsdoctor for more detailed performance data analysis.

I developed a packaging tool using webpack: rzpack. Now I want to support rspack packaging. As a new feature, rsdoctor is supported, but I want to keep it consistent with the usage of webpack. Do you have any plans to support it?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If this issue is still affecting you, please leave any comment (for example, "bump"). We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[LingyuCoder]

bump

[stale]

This issue has been automatically marked as stale because it has not had recent activity. If this issue is still affecting you, please leave any comment (for example, "bump"). We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!