[Bug]: Shared modules should still be defined even if external

[pcfreak30]

Describe the bug

I have been messing with the plugin and found if you try to externalize things like react or your own shared libraries they will not get put into the manifest or js as even stubs. The goal here is to be shared but call and rely on the global federation module registry instead.

Right now it seems that every bundle duplicates the shared libraries between them, even if it might not use them (ex being a singleton).

Version

6.0.11

Reproduction

will provide later

Relevant log output

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]

Hi @pcfreak30 thanks for the report.
Can you share a basic example of this issue?

[pcfreak30]

Hi @pcfreak30 thanks for the report. Can you share a basic example of this issue?

Im doing heavy r&d right now, but I can give you a config.

import { federation } from "@module-federation/vite";
import react from "@vitejs/plugin-react";
import * as fs from "fs";
import path, { dirname, resolve } from "path";
import * as process from "process";
import { fileURLToPath } from "url";
import { defineConfig } from "vite";
import { Plugin } from "vite";

const __dirname = dirname(fileURLToPath(import.meta.url));

export default defineConfig({
  base: "http://localhost:4173",
  build: {
    lib: {
      entry: resolve(__dirname, "src/index.ts"),
      fileName: "index",
      formats: ["es"],
    },
    minify: false,
    rollupOptions: {
      output: {
        minifyInternalExports: false,
      },
    },
    target: "esnext",
  },
  plugins: [
    react(),
    overrideHtmlInjection(),
    federation({
      exposes: {
        ".": "./src/index",
      },
      filename: "remoteEntry-[hash].js",
      manifest: true,
      name: "portal-framework-plugin-core",
      remotes: {},
      shared: {
        "@lumeweb/portal-framework-core": {
          singleton: true,
        },
        "react": {
          singleton: true,
        },
        "react-dom": {
          singleton: true,
        },
        "react-router": {
          singleton: true,
        },
      },
    }),
  ],
});

this works. but if i add the shared deps to external it does NOT. the goal here is to not duplicate dependencies between federated modules so when the parent bundles it the child can reference the registry, and not bring its own copy it wont use.

In the current impl I found the customResolver's in the proxySharedModule never get triggered if in external so special support may be needed to ensure it both does, and routes in the generated shims correctly.

[gioboa]

I see, feel free to drop a PR if you need library improvements

[jonick]

hi!
Any ideas on how to temporarily fix it?

[pcfreak30]

see #327 @jonick @gioboa i have submitted my solution to this.

[alebianco-doxee]

Hi @pcfreak30 sorry to reopen this thread but we just upgraded to 1.7.2 and found that, after the build, ALL css dependencies of ALL components are added to ALL shared and exposed modules.

For example both CSS imported by my local ComponentA and ComponentB are added to Vue, Pinia, ComponentA and ComponentB. And as soon Vue is loaded, all css of the whole federated module are loaded, which doesn't happen in 1.7.1.

If this is the indented behaviour, I'm not sure I've understood the original problem ...

[pcfreak30]

Hi @pcfreak30 sorry to reopen this thread but we just upgraded to 1.7.2 and found that, after the build, ALL css dependencies of ALL components are added to ALL shared and exposed modules.

For example both CSS imported by my local ComponentA and ComponentB are added to Vue, Pinia, ComponentA and ComponentB. And as soon Vue is loaded, all css of the whole federated module are loaded, which doesn't happen in 1.7.1.

If this is the indented behaviour, I'm not sure I've understood the original problem ...

Yes thats intended, at-least for me. There is no feasible way to isolate them as rollup does not expose enough metadata to know who is for who, and the behavior before was css was not processed at all.

I hope rolldown would enable better heuristics, but I found no data in the module graph reliable enough to identify atm.

[alebianco-doxee]

is there a specific demo or reproduction project to see the issue and fix at work?

maybe it's because we're using rsbuild on the host side but i don't think we experienced the problem you were describing with 1.7.1, even if we espose third party dependencies that have css and such

[pcfreak30]

is there a specific demo or reproduction project to see the issue and fix at work?

maybe it's because we're using rsbuild on the host side but i don't think we experienced the problem you were describing with 1.7.1, even if we espose third party dependencies that have css and such

The vite plugin did not have any css processing code, at all. Sorry I do not use rsbuild/webpack eco.

You can review https://github.com/module-federation/vite/pull/326/files (the before) to see the fact it never did anything with the css, so the manifest never got any css entries.

[alebianco-doxee]

yep, saw the changes and the resulting difference in the manifest after the build

strangely (maybe?) we had the css and all working fine in 1.7.1 even if it wasn't in the manifest and now the behaviour in 1.7.2 feels a bit aggressive to us. but it might be because the host uses the rsbuild modulefederation plugin and processes modules differently, not sure

if there's anything ready i'll try to create a vite only reproduction project on stackblitz or somewhere, just so i can understand the original issue better

[pcfreak30]

yep, saw the changes and the resulting difference in the manifest after the build

strangely (maybe?) we had the css and all working fine in 1.7.1 even if it wasn't in the manifest and now the behaviour in 1.7.2 feels a bit aggressive to us. but it might be because the host uses the rsbuild modulefederation plugin and processes modules differently, not sure

if there's anything ready i'll try to create a vite only reproduction project on stackblitz or somewhere, just so i can understand the original issue better

Simply reference a css file inside an exposed tsx react component for ex with 1.7.0 as css-in-js and you will find that it doesn't get added to the manifest. Also you will find in dev mode its not needed since everything loads ESM?

You can see my projects work and a real example here https://github.com/LumeWeb/web/blob/bec88900a4abf130b6960efc3837cbbd600a34a1/libs/portal-plugin-dashboard/src/ui/routes/dashboard.tsx#L5 https://github.com/LumeWeb/web/blob/bec88900a4abf130b6960efc3837cbbd600a34a1/libs/portal-plugin-dashboard/plugin.config.ts#L10. My pipeline though is complex enough I had to abstract it to a config wrapper function.

Also FYI, this is the wrong issue to be talking about this 🙃 .

[alebianco-doxee]

Also FYI, this is the wrong issue to be talking about this 🙃 .

isn't this the issue referenced in #326 ? is there another issue more relevant to the topic?

thanks for the tip on the project tho, i'll check it out