Replies: 1 comment 5 replies
-
Please create reproducible test repo, thank you |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Bug report
What is the current behavior?
First, some context to picture the problem.
I have a legacy project and I'm trying to use ModuleFederaionPlugin for step-by-step code replacement. I need to upgrade from vue v2 to vue3 in a very large codebase, so the ability to create isolated contexts and share common dependencies looks great to me. But there is still trouble. I have componential libraries, with some framework-independent logic (which I'd like to share), and two libraries based on them, dedicated to different versions of vue. Those libraries are under active development so I constantly receive updates, and my vue3 build is isolated in a nested workspace, and shared libs in that workspace often have newer versions than the libs in the root during development. Let the version in root be
0.24.23
, and0.24.24
in the nested workspace.Here are the options for a module federation in the root:
For build-next:
So, if I restrict the version of my library in buildNext to
=0.24.23
, eager consumption works. But if I remove the restriction, the build process does not fail, but the code of my website doesn't work and I get the messageShared module is not available for eager consumption
. I studied the problem and found out, that the loader doesn't take into account the eager flag of a shared entry.I have a list of versions like
So the loader uses the method
findVersion
and moves to 0.24.24, which is not intended for eager consumption, so I get a promise instead of a function and then get the error message.I also noticed, that if I have remote entries, my shared scope is flagged as a promise and according to loader logic, I should have gotten the error regardless of the eager flag, since I don't use
bootstrap
for the host. But there were no errors.If the current behavior is a bug, please provide the steps to reproduce.
Some steps are above in the description.
What is the expected behavior?
Eager consumption uses the correct version of my dependency. Well, actually, I've solved the problem locally by creating my own
ConsumeSharedModule
andConsumeSharedRuntimeModule
, and I need help with PR & review. I've read theCONTRIBUTING.md
and itsSubmitting Changes
section. I have trouble with the autotest step, not sure where I need to place them and where I can find existing tests for the plugin 😅 (to use them as an example, this is my first time testing things like this 😅).Here is the commit with my changes for review: cmath10@d5926d0
Other relevant information:
webpack version: v5.89.0
Node.js version: v16.20.2 (docker) / v18.17.1 (without docker)
Operating System: Linux Mint 21.3
Additional tools: ~
Beta Was this translation helpful? Give feedback.
All reactions