fix:13797 Pass shareScope to ContainerPugin via ModeuleFederationPlugin

[meetdheeraj]

This is to resolve #13797
This enables ModuleFederationPlugin to pass the shareScope prop down to ContainerPlugin which already knows how to handle it further.

Motivation
My office is currently discussing Microfrontends and various alternatives to implement the same. Webpack ModuleFederation was one of the option being discussed. Since ModuleFederation is fairly new, I had my doubts if we could use this and rely on it for our usecase. And so I was trying to read as much about it as I can. During this, I was also checking issues people were facing while using it which led me to #13797 which seemed like a crucial but easy to fix bug.
While that's how I came across this, this is my first commit to a open, community driven and public repository. So I'm bit on my nerves raising this PR. Do help me if I'm missing on any tradition. Thanks.

What kind of change does this PR introduce?

Bigfix for issue #13797 wherein ModuleFederationPlugin was not passing down options.shareScope to ContainerPlugin.
Since ContainerPlugin already accepts and handlesshareScope as required, no extra changes required on top of it.

Did you add tests for your changes?

This does not appear to require any. I ran all existing tests post my changes. Do advice if tests are still needed.

Does this PR introduce a breaking change?

Hopefully not.

What needs to be documented once your changes are merged?

Ideally, nothing. This just adds what was expected already.

[webpack-bot]

For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

[webpack-bot]

@meetdheeraj The most important CI builds failed. This way your PR can't be merged.

Please take a look at the CI results from azure (1 errors / 0 warnings) and appveyor (success) and fix these issues.

[alexander-akait]

Anyway can you add test case to avoid future regressions

[zhangzippo]

This is to resolve #13797 This enables ModuleFederationPlugin to pass the shareScope prop down to ContainerPlugin which already knows how to handle it further.

Motivation My office is currently discussing Microfrontends and various alternatives to implement the same. Webpack ModuleFederation was one of the option being discussed. Since ModuleFederation is fairly new, I had my doubts if we could use this and rely on it for our usecase. And so I was trying to read as much about it as I can. During this, I was also checking issues people were facing while using it which led me to #13797 which seemed like a crucial but easy to fix bug. While that's how I came across this, this is my first commit to a open, community driven and public repository. So I'm bit on my nerves raising this PR. Do help me if I'm missing on any tradition. Thanks.

What kind of change does this PR introduce?

Bigfix for issue #13797 wherein ModuleFederationPlugin was not passing down options.shareScope to ContainerPlugin. Since ContainerPlugin already accepts and handlesshareScope as required, no extra changes required on top of it.

Did you add tests for your changes?

This does not appear to require any. I ran all existing tests post my changes. Do advice if tests are still needed.

Does this PR introduce a breaking change?

Hopefully not.

What needs to be documented once your changes are merged?

Ideally, nothing. This just adds what was expected already.

hello, do you fix the problem ? i see it can't pass the test now?

[zhangzippo]

i am so sad, who can fixed this problem? shareScope not pass in ContainerPlugin, this will cause when init one remote container all the containers init. this happen in when you new mutil ModeuleFederationPlugin

[linux-foundation-easycla]

• ❌ - Dheeraj DeeKay The commit (28041a8) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[alexander-akait]

@meetdheeraj Can you accept CLA?

[snitin315]

@alexander-akait @TheLarkInn We can close this one too. It was fixed in #16031, I'm adding a test case for the same in #16943