__webpack_require__.l is not a function (follow up #551)

[grgrzybek]

Describe the bug

I see this issue closed:

• __webpack_require__.l is not a function after build in importRemote #551

But I'd like to share some findings.

There's something fishy between 3.1.83 and 3.1.85 where you've changed the builder (configuration) used (skip 3.1.84 where the different output wasn't yet reflected in package.json)

I'm just checking the difference between 3.1.83 and 3.1.85 (to narrow the scope).

I use a package with type=module and typescript with ES syntax (import), which means my:

import { importRemote } from '@module-federation/utilities'

brings in node_modules/@module-federation/utilities/dist/index.esm.js in version 3.1.83.

I'm using latest version of webpack bundler, so the above JS file lands in an output chunk in this shape (when output.chunkFormat = 'module'):

export const __webpack_esm_modules__ = {
  "../../node_modules/@module-federation/utilities/dist/index.esm.js"
  (__unused_webpack_module, __webpack_exports__, __webpack_require__) {
    __webpack_require__.r(__webpack_exports__);
    __webpack_require__.d(__webpack_exports__, {
      ...
      importRemote: () => (/* binding */ importRemote),
      ...
    });

    // ...

    const loadRemote = (url, scope, bustRemoteEntryCache) => new Promise((resolve, reject) => {
      const timestamp = bustRemoteEntryCache ? `?t=${new Date().getTime()}` : '';
      const webpackRequire = __webpack_require__;
      webpackRequire.l(`${url}${timestamp}`, (event) => {
        ...
  }
}

__webpack_require__ is taken from the 3rd argument of "../../node_modules/@module-federation/utilities/dist/index.esm.js" entry function

However in 3.1.85, the chunk contains:

export const __webpack_esm_modules__ = {
  "../../node_modules/@module-federation/utilities/dist/esm/utils/importRemote.mjs"
  (__unused_webpack___webpack_module__, __webpack_exports__, __webpack_require__) {
    __webpack_require__.r(__webpack_exports__);
    __webpack_require__.d(__webpack_exports__, {
      // only one
      importRemote: () => (/* binding */ importRemote)
    });

    // ...

    function __nested_webpack_require_187__(moduleId) {
      // Check if module is in cache
      var cachedModule = __webpack_module_cache__[moduleId];
      if (cachedModule !== undefined) {
          return cachedModule.exports;
      }
      // Create a new module (and put it into the cache)
      var module = (__webpack_module_cache__[moduleId] = {
          exports: {}
      });
      // Execute the module function
      __webpack_modules__[moduleId](module, module.exports, __nested_webpack_require_187__);

      // Return the exports of the module
      return module.exports;
    }

    (() => {
    __nested_webpack_require_187__.o = (obj, prop) => (Object.prototype.hasOwnProperty.call(obj, prop))
    })();

    const loadRemote = (url, scope, bustRemoteEntryCache) => new Promise((resolve, reject) => {
      const timestamp = bustRemoteEntryCache ? `?t=${new Date().getTime()}` : '';
      const webpackRequire = __nested_webpack_require_187__;
      webpackRequire.l(`${url}${timestamp}`, (event)=>{
        ...
  }
}

and while the passed (as 3rd argument) __webpack_require__ contains all necessary helpers:

the __nested_webpack_require_187__ has only the .o one:

See:

• https://webpack.js.org/api/module-variables/#__webpack_require__-webpack-specific
• https://webpack.js.org/plugins/internal-plugins/#compatibilityplugin

The changelog for 3.1.85 mentions:

- 918294f: Add runtime-safe access helpers for webpack require, webpack share-scope globals,
  and ignored dynamic imports, and migrate core/node runtime loaders to use these helpers.
  The helpers are exposed via a standalone `@module-federation/sdk/bundler`
  entrypoint so they can be built and consumed independently from the SDK main index bundle.

The cjs version of importModule.js (cjs/utils/importRemote.js) additionally defines __webpack_require__.r and __webpack_require__.d.

Webpack's CompatibilityPlugin kicks in because both cjs/utils/importRemote.js and esm/utils/importRemote.js actually DEFINE function named __webpack_require__ which triggers the rename (to __nested_webpack_require_187__) because of:

if (
	statement.type === "FunctionDeclaration" &&
	statement.id &&
	statement.id.name === RuntimeGlobals.require
) {

index.cjs.js and index.esm.js in 3.1.83 didn't declare such function - it only used the __webpack_require__ symbol assuming it's there (and it is when you bundle these files using webpack.

Reproduction

not that easy - but try to run importRemote() in 3.1.83 and 3.1.85

Used Package Manager

yarn

System Info

Using Webpack with @module-federation/utilities 3.1.83 and 3.1.85

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.
• Make sure this is a Module federation issue and not a framework-specific issue.
• The provided reproduction is a minimal reproducible example of the bug.

[2heal1]

Hey , try @module-federation/runtime to handle mf lifycycle

https://module-federation.io/guide/runtime/index.html

[grgrzybek]

Sure - I saw the recommendation at https://www.npmjs.com/package/@module-federation/utilities, but still I wanted to share the analysis about how CompatibilityPlugin kind of broke the legacy version.

[2heal1]

@module-federation/utilities is part of the Module Federation v1 ecosystem. Since Module Federation v2, we’ve redesigned the runtime from the ground up, and most of the functionality previously provided by this package has been incorporated into the new runtime architecture.

Because of that, we no longer recommend using @module-federation/utilities for new projects. It also hasn’t been actively maintained for quite some time.

If you’re using Module Federation v2, it’s better to use the APIs provided by @module-federation/runtime instead. Let us know what you’re trying to achieve, and we can point you to the recommended v2 approach.