You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Shakapacker is a popular library for handling JS bundling in Rails apps. It's the successor to rails/webpacker and uses webpack-assets-manifest as a core component. There's ongoing discussion about adding Rspack as a bundler option for Shakapacker (see issue #476), but the lack of support for webpack-assets-manifest in Rspack is a significant roadblock.
Current Progress
I've forked the original webpack-assets-manifest plugin and started adapting it for Rspack. Most of the test coverage is passing, but there are still some issues. You can see the current state of the refactor here: rspack-assets-manifest test results.
To complete the port, Rspack needs to support or provide alternatives for the following webpack features:
codeGenerationResults: Used in the original plugin to gather asset information.
assetsInfo: Used to store and retrieve additional information about assets.
We could either:
Add similar properties or methods to Rspack's compilation object.
Provide alternative APIs that serve the same purpose but fit better with Rspack's architecture.
Think about workarounds or patterns to achieve the same results without these specific properties.
Benefits
Enable easier migration from webpack to Rspack for projects using Shakapacker.
Increase Rspack's compatibility with existing webpack ecosystems. (as the lib itself has >600k downloads/week)
Potentially benefit other projects that rely on webpack-assets-manifest.
I'm willing to contribute to this feature's implementation, but I would need some direction on Rspack's internal architecture and best practices for adding these or equivalent features.
What does the proposed API of configuration look like?
.
The text was updated successfully, but these errors were encountered:
The assetsInfo can be got by compilation.getAsset()[].info. If you need to override it, you can use compilation.updateAsset(), but currently it does not support custom field (the rawRequest is not supported but the sourceFilename is supported).
Seems there is no method to get the code generation data of asset modules. But the assets of these modules will always be emitted through compilation.emitAsset and can be got from compilation.getAssets(). They have sourceFilename in their infos. You can also get all modules by compilation.modules so I think you can gather asset information by combining sourceFilename and module.userRequest/rawRequest.
I tried to replace webpack-assets-manifest with rspack-manifest-plugin, but it doesn't support entrypoints as I see.
According to this page rspack is compatible with webpack-assets-manifest, however compilation fails because rspack.Compilation does not have codeGenerationResults property
What problem does this feature solve?
Background
Shakapacker is a popular library for handling JS bundling in Rails apps. It's the successor to
rails/webpacker
and useswebpack-assets-manifest
as a core component. There's ongoing discussion about adding Rspack as a bundler option for Shakapacker (see issue #476), but the lack of support forwebpack-assets-manifest
in Rspack is a significant roadblock.Current Progress
I've forked the original
webpack-assets-manifest
plugin and started adapting it for Rspack. Most of the test coverage is passing, but there are still some issues. You can see the current state of the refactor here: rspack-assets-manifest test results.To complete the port, Rspack needs to support or provide alternatives for the following webpack features:
codeGenerationResults
: Used in the original plugin to gather asset information.assetsInfo
: Used to store and retrieve additional information about assets.We could either:
Benefits
webpack-assets-manifest
.I'm willing to contribute to this feature's implementation, but I would need some direction on Rspack's internal architecture and best practices for adding these or equivalent features.
What does the proposed API of configuration look like?
.
The text was updated successfully, but these errors were encountered: