Wrong "path" argument type when using NativeFederationTypeScriptRemote

[nvhungkt]

Describe the bug

When I try to use NativeFederationTypeScriptRemote with ModuleFederationPlugin, I got an error: The "path" argument must be of type string. Received an instance of Object

My config:

const { ModuleFederationPlugin } = require('@module-federation/enhanced/webpack');
const { NativeFederationTypeScriptRemote } = require('@module-federation/native-federation-typescript/webpack');

...
new ModuleFederationPlugin(federationConfig),
NativeFederationTypeScriptRemote({
  moduleFederationConfig: federationConfig,
}),

I try to debug further, and I found that because ModuleFederationPlugin mutates federationConfig.exposes object
Here is the mutation
https://github.com/module-federation/core/blob/main/packages/enhanced/src/lib/container/ModuleFederationPlugin.ts#L134
options.exposes = containerManager.containerPluginExposesOptions;

I can workaround by moving ModuleFederationPlugin below NativeFederationTypeScriptRemote, or using spread ModuleFederationPlugin({ ...federationConfig })

But please fix this issue, avoid the mutation.

Reproduction

.

Used Package Manager

npm

System Info

System:
    OS: macOS 15.2
    CPU: (11) arm64 Apple M3 Pro
    Memory: 3.05 GB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.9.0 - ~/.nvm/versions/node/v22.9.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v22.9.0/bin/yarn
    npm: 10.8.3 - ~/.nvm/versions/node/v22.9.0/bin/npm
    bun: 1.1.30 - ~/.bun/bin/bun
  Browsers:
    Chrome: 133.0.6943.99
    Safari: 18.2

Validations

• Read the docs.
• Read the common issues list.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[ScriptedAlchemy]

it will not be trivial to address ordering concerns between plugin execution flows. You can submit a pr to the native type plugin that will throw error if it sees the compiler plugins are in the wrong order - this is a common issue in cross plugin integrations

[nvhungkt]

@ScriptedAlchemy it's not about plugin execution flows. I think it's because ModuleFederationPlugin unnecessarily mutates configuration object.
Fixing that mutation logic would be better.