Strange correlation between how you import shared lib's aliases declared in the package.json "exports" and mf plugin

[sirAbramstone]

Repro on stackblitz

We encountered some strange behaviour when started migrating from webpack + mf onto vite + mf using this plugin. Repro (link above) contains 3 projects that represent a host, a remote app and a shared library. The shared library explicitly provides access to its exports by declaring them in the 'exports' section of its package.json.

The problems started when we encountered some circular dependencies inside the shared lib (you can see them if you take a look at files shared/src/utils/now.js & shared/src/circ/foo.js). The thing is, tools like madge don't consider this to be circular dependencies. But if you run script dev:remote from the root package.json, you'll see that the remote serve is broken, Vue app is not being created, and there are no errors in the console.

The further you go the weirder it gets: if you fix the import in the files above and add them, for example, '. xxx' at the end of the string, like import {getState} from 'shared/utils.xxx' (I reserved such aliases in the 'exports' section of the shared lib's package.json) and restart the script - it will start working! You can go further and also run dev:host to see how remote application will be loaded dynamically by the host & they will share the same state from the shared lib (shared/src/utils/getState.js):

But if you start using such import paths (some-path + .xxx) outside of the shared lib in the host & and in the remote - they lose their shared state:

You can also delete creation of mf/vite plugin from vite configs and see that the remote starts working just fine (no need to rewrite import paths from the shared), but of course you'll lose module federation feature in this case.

Can anyone explain what's going on here and how to fix it?

[zhangHongEn]

I haven’t been able to reproduce the same result as you; I can’t even display the page properly.

[zhangHongEn]

It seems to be related to the "shared": "file:../shared" configuration

[sirAbramstone]

Hi, @zhangHongEn, thanks for your reply

I haven’t been able to reproduce the same result as you; I can’t even display the page properly.

I updated repro, so now it works from the beginning. Run dev:remote from the root package.json to see that the remote app is built & previewed and then abort this behaviour by changing the import path in the files shared/src/utils/now.js or shared/src/circ/foo.js. Just delete '.xxx' from the end of the string, e.g. import {getState} from 'shared/utils.xxx' -> import {getState} from 'shared/utils', restart dev:remote and you will see a blank page without the created Vue application.

It seems to be related to the "shared": "file:../shared" configuration

Unfortunately, this is not the root of the problem, because our IRL 'shared' library is a published npm package, and that's where we started to struggle. I'm using a local dumb version of this library just for simplicity's sake.

If you're wondering why you even need to bother with this issue, I'll point out that Vite doesn't have any problems with solving circular dependencies, but the plugin apparently does. You can verify this if you remove the useViteFederation function call from the vite.config.js remote project (the plugin instance is created there) and restart the dev:remote script. You will see that the project is built and served without problems

[zhangHongEn]

@sirAbramstone I think this issue will take quite a bit of time. Sorry, but I won’t be able to look at it until next week.

[zhangHongEn]

Although I’m not sure if it will work, you might try shared: ["npmpkg/"]