refactor(vue3-bridge): refactor of createBridgeComponent to add the ability to register plugins inside the function

[Dell-it]

A small refactor of createBridgeComponent to add the ability to register plugins inside the function.

Description

1. Added type annotations for the argument in the createBridgeComponent function.
2. Added passing the instance of the created Vue-application to appOptions so that necessary plugins can be registered in this callback.
3. Made router returned from appOptions optional.
4. Fixed issues reported by TypeScript and ESLint, including allowing beforeBridgeRenderRes to be a promise.
5. Updated the documentation.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated the documentation.

---

Are we sure that appOptions should return the actual instance of the Vue Router rather than just the necessary parameters?

In my case, I have to create the router inside the addOptions callback to pass it to createBridgeComponent, where another router instance will be created.

Maybe we could consider returning something like this from addOptions instead:

{
  router: {
    options: RouterOptions,
    routes: RouteRecordNormalized[]
  }
}

[changeset-bot]

🦋 Changeset detected

Latest commit: 6d52726

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 27 packages

Name	Type
@module-federation/bridge-vue3	Patch
@module-federation/runtime	Patch
@module-federation/enhanced	Patch
@module-federation/rspack	Patch
@module-federation/webpack-bundler-runtime	Patch
@module-federation/sdk	Patch
@module-federation/runtime-tools	Patch
@module-federation/managers	Patch
@module-federation/manifest	Patch
@module-federation/dts-plugin	Patch
@module-federation/third-party-dts-extractor	Patch
@module-federation/devtools	Patch
@module-federation/bridge-react	Patch
@module-federation/bridge-shared	Patch
@module-federation/bridge-react-webpack-plugin	Patch
@module-federation/modern-js	Patch
@module-federation/retry-plugin	Patch
@module-federation/data-prefetch	Patch
@module-federation/rsbuild-plugin	Patch
@module-federation/error-codes	Patch
@module-federation/nextjs-mf	Patch
@module-federation/node	Patch
@module-federation/storybook-addon	Patch
@module-federation/modernjsapp	Patch
@module-federation/esbuild	Patch
@module-federation/utilities	Patch
website-new	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

✅ Deploy Preview for module-federation-docs ready!

Name	Link
🔨 Latest commit	6d52726
🔍 Latest deploy log	https://app.netlify.com/sites/module-federation-docs/deploys/675508e39caeb100085a51a4
😎 Deploy Preview	https://deploy-preview-3297--module-federation-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Dell-it]

Hello!
Actually, I have another problem that I can't solve in a simple way. I feel like I'm missing something, and maybe you can point me in the right direction.

When I integrate my remote application into a page, and it has its own routes, browser navigation within the microfrontend works perfectly. But if I navigate to another page in the host application, the browser's "Back" button will not take me back to the remote application. Instead, it will lead to a non-existent page.

For example, I have:

• /home/ - a page in the host application
• /module-federation/:pathMatch(.*)* - a page where the remote application with its own router is rendered. The router has:
  • /module-federation/page1
  • /module-federation/page2

When I navigate between /page1 and /page2 inside the remote application, Vue router and browser history work correctly. But my window.history.state looks like this:

back: "/page1"
current: "/page2"

When I navigate to /home, the browser's "Back" button takes me to /page2 instead of /module-federation/page2.
I will be glad for any hints, thanks!

P.S. Vue-router in createBridgeComponent is configured with the correct base: '/module-federation'.

[Dell-it]

So far, I have only found the issue to be that the remote application has its own base path, such as /module-federation, which is not accounted for in the router. This causes it to be lost in the historyState of the vue-router when navigating back to the host application. In the Vue Router issues, I saw a post where the creator mentions that in such cases, the same createWebHistory instance should be used across routers. I tried this approach, and it actually worked.

However, currently, there is no way to pass the createWebHistory instance into createBridgeComponent. Perhaps it would make sense to add this capability, for example, as a parameter returned from addOptions?

But how is it better to get the createWebHistory instance from the host application? At the moment, I am passing it using the window object. However, since createBridgeComponent is executed in the context of the host application, perhaps you can suggest a more correct way to do this?