Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async shared modules not resolved correctly with module federation. #3003

Open
5 tasks done
HariAbinesh opened this issue Sep 27, 2024 · 7 comments
Open
5 tasks done

Comments

@HariAbinesh
Copy link

Describe the bug

NPM Package App1.js

const user = {
    name: "Ashok kumar D",
    age: "30"
};
 export {
    user
 };

NPM Package index.js

const {user} = await import("./app1");
export {
    user
};

While using above mentioned npm. package in App, the static import resolves to parent promise object instead of resolved object.

const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('@module-federation/enhanced');
const path = require('path');
const deps = require('./package.json').dependencies;

/**
 * @type {import('webpack').Configuration}
 **/
const webpackConfig = {
  entry: './src/index',
  mode: 'development',
  devServer: {
    devMiddleware: {
      writeToDisk: true
    },
    static: {
      directory: path.join(__dirname, 'dist'),
      
    },
    port: 3001,
  },
  experiments: {
    topLevelAwait: true
  },
  output: {
    publicPath: 'auto',
  },
  module: {
    rules: [
      {
        test: /\.m?js$/,
        type: 'javascript/auto',
        resolve: {
          fullySpecified: false,
        },
      },
      {
        test: /\.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options: {
          presets: ['@babel/preset-react'],
        },
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      library: { type: 'var', name: 'app1' },
      remotes: {
        app2: 'app2',
      },
      shared: {
        "top-level-await-module-fed-issue": {
          eager: true
        },
        'react-dom': {
          import: 'react-dom', // the "react" package will be used a provided and fallback module
          shareKey: 'react-dom', // under this name the shared module will be placed in the share scope
          shareScope: 'legacy', // share scope with this name will be used
          singleton: true, // only a single version of the shared module is allowed
        },
        // oldReact: {
        //   import: "react", // the "react" package will be used a provided and fallback module
        //   shareKey: "oldReact", // under this name the shared module will be placed in the share scope
        //   shareScope: "legacy", // share scope with this name will be used
        //   singleton: true, // only a single version of the shared module is allowed
        // }
      },
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
      app2RemoteEntry: getRemoteEntryUrl(3002),
    }),
  ],
};

module.exports = webpackConfig;

function getRemoteEntryUrl(port) {
  const { CODESANDBOX_SSE, HOSTNAME = '' } = process.env;

  // Check if the example is running on codesandbox
  // https://codesandbox.io/docs/environment
  if (!CODESANDBOX_SSE) {
    return `//localhost:${port}/remoteEntry.js`;
  }

  const parts = HOSTNAME.split('-');
  const codesandboxId = parts[parts.length - 1];

  return `//${codesandboxId}-${port}.sse.codesandbox.io/remoteEntry.js`;
}

Actual App code

import {user} from "top-level-await-module-fed-issue";
import('./bootstrap');
console.log(user);
export { };
Screenshot 2024-09-27 at 3 47 15 PM

What is the expected behavior?
Imported modules from module federation should resolve normally whether it's async modules or not

Reproduction

https://github.com/HariAbinesh/top-level-await-module-fed-issue-app

Used Package Manager

npm

System Info

node: 20

Validations

@HariAbinesh
Copy link
Author

webpack/webpack#15044

@ScriptedAlchemy
Copy link
Member

The remote is not set to esm output, its set to var - so top level await is not possible in that runtime.
Set the federation to library.type = module

@HariAbinesh
Copy link
Author

@ScriptedAlchemy The Issue exists even if we use type module. I have updated the changes in that Repo

Without Module Federation plugin and outputModule, topLevelAwait converts properly in webpack ( without esm runtime ).

@ScriptedAlchemy
Copy link
Member

The repo seems incomplete. There is only one app

@HariAbinesh
Copy link
Author

HariAbinesh commented Oct 8, 2024

@ScriptedAlchemy Yes, when Module Federation is configured, single App itself ( which shares its libraries with remote ) which has shared library fails to load. No two Apps are required for this case. This is the Base App.

  new ModuleFederationPlugin({
      name: 'app1',
      library: { type: 'module', name: 'app1' },
      remotes: {
        app2: 'app2',
      },
      shared: {
        "top-level-await-module-fed-issue": {
          eager: true
        },
        'react-dom': {
          import: 'react-dom', // the "react" package will be used a provided and fallback module
          shareKey: 'react-dom', // under this name the shared module will be placed in the share scope
          shareScope: 'legacy', // share scope with this name will be used
          singleton: true, // only a single version of the shared module is allowed
        },
        // oldReact: {
        //   import: "react", // the "react" package will be used a provided and fallback module
        //   shareKey: "oldReact", // under this name the shared module will be placed in the share scope
        //   shareScope: "legacy", // share scope with this name will be used
        //   singleton: true, // only a single version of the shared module is allowed
        // }
      },
    }),

@ScriptedAlchemy
Copy link
Member

Should probably be fixed in the webpack core core.

@ScriptedAlchemy
Copy link
Member

You can workaround it with a runtimePlugin though, and await the inner result then return that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants