[Bug]: Cannot load shared dependencies for the first time

[wojtask9]

Describe the bug

npm i
npm run dev

open in browser http://localhost:5010/app-1

in console.log there be an error.

After pressing F5 everything is OK and everything works correct.

To reproduce bug you must kill npm run dev and launch again.

This issue is also reproduced with lastest versions (everything including vite, vue, module-federation, etc).

Not sure where the problem is but if you remove shared from remote apps (app1, app2) then issue doesn't exists.
Also porting to non deprecated init to use registerRemotes and checking if getInstance() != null (always is not null) issue still exists.

Issue exists in firefox and chrome. I'm using linux env.

This repo is taken from https://dev.to/lmlonghuynh/building-a-micro-frontend-architecture-with-vue-3-vite-and-module-federation-1bb1

Version

probably all

Reproduction

https://github.com/lmlong-huynh/micro-frontend-sample

Relevant log output

[MF] Error loading remote module: Error: [ Federation Runtime ]: Please call createInstance first. #RUNTIME-009
View the docs to see how to solve: https://module-federation.io/guide/troubleshooting/runtime/RUNTIME-009
    error2 logger.ts:22
    assert2 logger.ts:10
    loadShare index.ts:71
    res chunk-DW7XOL6G.js:17
    promise callback*node_modules/__mf__virtual/app1__loadShare__vue__loadShare__.js chunk-DW7XOL6G.js:17
    __require chunk-ZKAWKZG5.js:11
    <anonymous> chunk-DW7XOL6G.js:31

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.
• The provided reproduction is a minimal reproducible example of the bug.

[gioboa]

Thanks for your report.
This is a community project, PRs are more than welcome 🤗 thanks

[wojtask9]

@gioboa my knowledge is too low :) I don't know where problem is.

[gioboa]

I see, don't worry, my comment is directed to the community in general.

[sabov]

I'm facing the same issue. After a bit of experimentation I found two possible workarounds:

• As you mentioned you can remove the shared module
• Downgrade to vite 5.x.x.

Here is a fork of the examples that illustrates the issue and two workarounds (1, 2).
Interesting that in my example the host is using runtime federation only but the example @wojtask9 provided uses the build time plugin.

I'm happy to give it a try and work on a PR but any hints on the root cause are welcome.

[gioboa]

Mmm interesting.
Is Vite 5 the latest working version?

[wojtask9]

yes. it works also for me with vite 5.x ( lastest 5.4.21). First broken version is vite 6.0.0

[gioboa]

I see, that's an interesting hint for starting the debugging.
Btw this error comes from the core package I guess.

[wojtask9]

@gioboa currently I'm not sure what core is :) (module-federation/core or vite/core) ?

my lastest test

1. start app
2. open app in chrome (error exists)
3. open app in firefox (no error)
4. restart app
5. open app in firefox (error exists)
6. open app in chrome (no error)

it looks like first request vite changes something.

@sabov can you confirm my observation ?

BTW:
error occures in line from app1 not host var res = initPromise.then( (_) => loadShare("vue", {

/* already-processed-by-dev-proxy-module-top-level-await */
import {require_app1_mf_v_runtimeInit_mf_v} from "/node_modules/.vite/deps/chunk-5A7UUFGP.js?v=ad4590d8";
import {require_index_cjs} from "/node_modules/.vite/deps/chunk-NEL34RLI.js?v=ad4590d8";
import {__commonJS} from "/node_modules/.vite/deps/chunk-ZKAWKZG5.js?v=ad4590d8";

// node_modules/__mf__virtual/app1__loadShare__vue__loadShare__.js
var require_app1_loadShare_vue_loadShare = __commonJS({
    "node_modules/__mf__virtual/app1__loadShare__vue__loadShare__.js"(exports, module) {
        var {loadShare} = require_index_cjs();
        var {initPromise} = require_app1_mf_v_runtimeInit_mf_v();
        var res = initPromise.then( (_) => loadShare("vue", {
            customShareInfo: {
                shareConfig: {
                    singleton: true,
                    strictVersion: false,
                    requiredVersion: "^3.5.25"
                }
            }
        }));
        var exportModule = (/*mf top-level-await placeholder replacement mf*/
        res.then( (factory) => factory()));
        module.exports = exportModule;
    }
});

const __mfproxy__awaitrequire_app1_loadShare_vue_loadShare = await require_app1_loadShare_vue_loadShare();
const __mfproxy__require_app1_loadShare_vue_loadShare = () => __mfproxy__awaitrequire_app1_loadShare_vue_loadShare;

export {__mfproxy__require_app1_loadShare_vue_loadShare as require_app1_loadShare_vue_loadShare};

[gioboa]

Yep, the message is defined inside mfe/core
We can try to set breakpoints and verify why it's failing the first run.

[wojtask9]

aaa that's simple :)

https://github.com/module-federation/core/blob/20c51c36b70346654d10a171907bdaf10e4e0ffe/packages/runtime/src/index.ts#L71

FederationInstance is null

[wojtask9]

not sure but it looks similar
#68

You are on windows or something else ?

[gioboa]

You are on windows or something else ?

I reproduced it with the latest version and the repo in the first comment.
I'm on linux