Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Webpack 5 entry dependOn property with UMD exports does not allow AMD loader to load dependent modules

See original GitHub issue

Bug report

What is the current behavior?

The newly-introduced dependOn feature to be released with Webpack 5 seems to have non-deterministic behaviour when exporting UMD modules and using a require-based (i.e. AMD) loader.

What appears to be the fundamental issue is that an import of a module that depends on another does not result in a proper import of the dependent module; e.g. if Module A depends on Module B, then a simple define([ModuleA], function(ModuleA) { ... }) does not seem to kick off a proper require of Module B.

If the current behavior is a bug, please provide the steps to reproduce.

webpack.config.js snippet:

entry: {
  ModuleC: `${process.cwd()}/ModuleC`,
  ModuleB: {
    import: `${process.cwd()}/ModuleB`,
    dependOn: 'ModuleC',
  },
  ModuleA: {
    import: `${process.cwd()}/ModuleA`,
    dependOn: ['ModuleB', 'ModuleC'],
  }
},
output: {
  path: `${process.cwd()}/dist`,
  filename: '[name].js',
  library: 'modules',
  libraryTarget: 'umd'
}

Module A:

import ModuleB from './ModuleB';
import ModuleC from './ModuleC';

const ModuleA = function() {
  console.log('A');
  ModuleB();
  ModuleC();
};

export default ModuleA;

Module B:

import ModuleC from './ModuleC';

const ModuleB = function() {
  console.log('B');
  ModuleC();
};

export default ModuleB;

Module C:

const ModuleC = function() {
  console.log('C');
};

export default ModuleC;

Bundling these with webpack results in strange behaviour - I have created a couple of scenarios in my minimal test github repo to demonstrate this:

In basepage-1.html, I test out the simpler case of simply loading ModuleA (in main-1.js) in the browser. This doesn’t ever work (breakpoints indicate that require simply returns a number like 1 or 2). The network indicates that no attempt is made to load ModuleB or ModuleC.
In basepage-2.html, I test out the more complex case of loading all of the Modules C through A (in that order, in main-2.js). Continual refreshes of the browser sometimes allows different modules to work, but the actual output of the first ModuleX.default() call can change depending on what I assume to be the result of a race condition of the module loads.

What is the expected behavior?

In basepage-1.html (i.e. main-1.js), I expect ModuleA to successfully load ModuleB and ModuleC, resulting in an output of:

A    // Here begins output of ModuleA
B
C
C

In basepage-2.html (i.e. main-2.js), I expect all three modules to load successfully, and the calls to the functions resulting in an output of:

C    // Here begins output of ModuleC
B    // Here begins output of ModuleB
C
A    // Here begins output of ModuleA
B
C
C

If I remove the dependOn field from my webpack config and load the three non-dependent chunks as regular entry points, there is no race condition and all modules load properly and provide the proper output.

Other relevant information: webpack version: 5.0.0-beta.14 Node.js version: 10.18.1 Operating System: macOS Mojave 10.14.6 Additional tools:

Any recent-ish Chrome browser version
RequireJS (found here: https://requirejs.org/docs/release/2.3.6/minified/require.js)

Issue Analytics

State:
Created 4 years ago
Reactions:1
Comments:9 (3 by maintainers)

Top GitHub Comments

7reactions

JasperTeycommented, Jan 8, 2021

I am also experiencing similar weirdness with dependOn. My understanding was that the introduction of dependOn would facilitate the use case of including multiple entry scripts into an HTML page, something that was originally raised pre-v5 (see https://github.com/webpack/webpack/issues/8842).

Citing the use case in that thread by @lostPixels:

<html>
    <head>
        <script src='vendors.bundle.js' />
        <script src='global.bundle.js' />
        <script src='mypage.bundle.js' />
    </head>
    <body>
    ...
    </body>
</html>

My understanding was that the above would now be possible if you defined the entries something to the effect of:

const entries = {
	'vendors': './vendors.bundle.js',
	'global': './global.bundle.js',
	'mypage': {
		import: './mypage.bundle.js',
		dependOn: ['vendors', 'global']
	}
};

…but I’m not really sure anymore. Can anyone confirm or offer more insight?

0reactions

sysofwancommented, Jun 21, 2022

+1 I don’t see the point of dependOn if this is not supported.

Top Results From Across the Web

Entry and Context - webpack

The entry object is where webpack looks to start building the bundle. The context is an absolute string to the directory that contains...

Externals - webpack

The externals configuration option provides a way of excluding dependencies from the output bundles. Instead, the created bundle relies on that dependency ......

Other Options - webpack

a dependency is currently compiling or invalid. Remember that current configuration will not compile until its dependencies are done. webpack.config.js module.

Entry Points - webpack

The single entry syntax for the entry property is a shorthand for: webpack.config.js module.exports ... import : Module(s) that are loaded upon startup....

Output - webpack

path option. For a single entry point, this can be a static name. webpack.config.js module.exports ...