Implementing a plugin that needs custom Module?

[kenrick95]

Hi,

I'm currently migrating our company's project to use Rspack. One of our use case is that it is implementing a customized version of "module federation", therefore in our code base, we implement something like

function createCustomMfModule(webpack) {
    const { Module } = wepback;
    return class CustomMFModule extends Module {
         // ....
    }
}

Then it is used at NormalModuleFactory's factorize:

class CustomMfPlugin {
    apply(compiler) {
        compiler.hooks.normalModuleFactory.tap(PLUGIN_NAME, normalModuleFactory => {
            normalModuleFactory.hooks.factorize.tapPromise(PLUGIN_NAME, async resolveData => {
                const request = resolveData.request;
                if ( /* some condition not met */ ) {
                    return; // use normal way of bundling
                }
                // use our custom mf
                return new createCustomMfModule(compiler.webpack);
            }
        }
    }
}

There are two problems here:

1. In the docs, I found the warning "Returning module instance is not supported for now. This hook will affect the module creation process, so use it with caution."
2. Rspack doesn't allow us to extend webpack.Module and therefore we cannot use our CustomMFModule at all

Do you have suggestion on how to work around for these issues? Or would you suggest to fork Rspack core to implement this plugin in Rust?

Thanks

[SyMind]

@kenrick95 Would you be willing to provide a relatively complete example? Can reflect your needs for us to evaluate.

[kenrick95]

Apologies I couldn't provide a complete example, since it is part of company codes and it also contains many concepts only available internally

However, the idea is similar to

https://github.com/module-federation/core/blob/60a5aa4700655cc57c92d32bfec1ae37f25530ee/packages/enhanced/src/lib/container/ContainerReferencePlugin.ts#L110-L139

and https://github.com/module-federation/core/blob/60a5aa4700655cc57c92d32bfec1ae37f25530ee/packages/enhanced/src/lib/container/RemoteModule.ts#L35

but the implementation is very different because we want the code generation part to be different and calls our global variables

[kenrick95]

okay... discussed internally, it seems like better for us to adopt the public Module-Federation.io architecture so we can align better with open source solutions and to leverage Rspack. We shall study the new Module Federation 2.0 and will proceed from there. Thanks for taking your time to consider this issue

[h-a-n-a]

Hey, we're planning to roll out an experimental support for running custom Rust plugins in Rspack. It's a custom binding that can be used with @rspack/core. Let me know if you want to give it a try!

[kenrick95]

@h-a-n-a Wow that is nice! I think I'm interested in trying out!

[h-a-n-a]

I would first suggest you adopting the MF architecture. It's easier. If this does not help, then use custom Rspack binding.

The rationale of custom Rspack binding is to let users to create their own binding package. Help users to leverage their own plugins and loaders(the latter hasn't supported).

To give you a rough overview of the current architecture of Rspack, I will first introduce some behind-the-scene work of @rspack/core. So the@rspack/core package, which plays an very important part in interacting between JS and Rust, is the one which drives @rspack/cli and can also be used programmatically. The core package then imports @rspack/binding. It's a package that exports the raw node addon . This package needs to be compiled with respect to the target platform on which people are to use @rspack/core. This is already getting complicated enough! And that's the reason I recommend you to stick to the MF architecture.

In our experimental custom binding architecture, which we haven't wrote a doc yet, developers need to compile their own plugin along with the current existing binding located in Rspack repo (crates/node_binding). It's like adding some strawberry jam on a loaf of bread you purchased from some local bakery except that the strawberry jam is actually your plugin and the bread is crates/node_binding. This is not quite a good metaphor, but you know what I'm saying: It's linked statically.

Then, you get the binding and to use this binding, you just need to set RSPACK_BINDING env to let @rspack/core use your binding and register the plugin that you wrote. (See: #10857)

[kenrick95]

Understand! Thanks for providing advise and also alternative for my situation 🙏