Proposed fix to module federation to stop ignoring the singleton flag when requiredVersion is false

[colacadstink]

This addresses (fixes #14795) . Previously, when using module federation, if requiredVersion was false, the singleton flag would be entirely ignored. Since it's entirely valid to require one instance of a package be instantiated, but not care at all what version it is, this seems like an oversight.

What kind of change does this PR introduce?

The core of this change is in ConsumeSharedModule.codeGeneration, which now includes logic for when requiredVersion is false but singleton is true. Specifically, it causes the generated code to call one of two new functions - loadSingleton, or loadSingletonFallback if a fallback is present. The code for these new functions is located in ConsumeSharedRuntimeModule.generate, along with a helper function, getSingleton, which acts similarly to getSingletonVersion but without doing a semver check.

Did you add tests for your changes?

I did not. Pardon my ignorance, but I can't figure out where or how to add a test for this.

Does this PR introduce a breaking change?

No, or at least, I wouldn't think so. This technically changes the behavior of webpack, but I'd be shocked if anyone was depending on the existing behavior, given how this appears to be a bug instead of an intended feature.

What needs to be documented once your changes are merged?

Nothing, I don't think - this code change makes the code work as I'd expect from the current documentation, so I don't think any changes would be needed.

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Ben Harris (92e3730)

[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)

[vankop]

pls add test cases

[vankop]

You can edit test case in test/configCases/container/* (there are some with ConsumeSharedPlugin) or add your one in this directory

to run only your test case node node_modules/.bin/jest test/ConfigTestCases.basictest.js -t=directory-name

[sokra]

You can edit test case in test/configCases/container/* (there are some with ConsumeSharedPlugin) or add your one in this directory

And there are more regarding sharing in test/configCases/sharing

to run only your test case node node_modules/.bin/jest test/ConfigTestCases.basictest.js -t=directory-name

yarn jest ConfigTest -t directory-name

[sokra]

Code changes look good.

[webpack-bot]

@colacadstink Thanks for your update.

I labeled the Pull Request so reviewers will review it again.

@vankop Please review the new changes.

[colacadstink]

Massive thank you @sokra for pointing me to the sharing tests - I was able to very easily modify that to test what I added (and ended up catching a typo in the process - this is why we test!)

[webpack-bot]

Hi @colacadstink.

Just a little hint from a friendly bot about the best practice when submitting pull requests:

Don't submit pull request from your own main branch. It's recommended to create a feature branch for the PR.

You don't have to change it for this PR, just make sure to follow this hint the next time you submit a PR.

[sokra]

Thanks