question-mark
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.

When using AMD output, use AMD for code-split chunks as well

See original GitHub issue

Do you want to request a feature or report a bug?

A new feature that would improve code-splitting with externals.

What is the current behavior?

Context : An application which is build with multiple sub-applications which are each built with Webpack, and the “orchestration” of loading all this is done through requirejs. One of the things with this platform, is that react is provided through requirejs so that each plugin can reuse a single global library instead of re-loading it for each app. (Any other library could be provided globally, I use react as the example here) /context

When we generate a library in amd with some externals and code-splitting. The thing is that externals are defined only at the main level even though it’s the code-split part that need those externals.

Example :

// main.min.js
define(['react'], function(a) { /* Doesn't actually need react yet */ });

// 1.main.min.js
webpackJsonp([0],{3: function() { /* actually needs react */});

Wouldn’t it be better if it was able to generate it this way ?

// main.min.js
define(function() { /* Doesn't actually need react yet */ });

// 1.main.min.js
define(["react"], function(a) {
  return {
    chunkIds: [0],
    moreModules: {3: function() { /* actually needs react */}}
  }
});

Advantages are :

  • no custom logic to load modules, requirejs knows how to do it.
  • external dependencies are loaded when they’re actually needed
  • no need to specify a name for the jsonp function as it’s done through requirejs

Problem with the current implementation:

  • externals might be loaded too early, which defeats the purpose of code splitting and lazy loading of those parts.

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

It isn’t a bug, just the normal behaviour that could be more optimal

What is the expected behavior?

To load externals once they are needed

If this is a feature request, what is motivation or use case for changing the behavior?

My motivation is that I have an application that supports plugins, each of those can be implemented with any techology, React, jquery, vanilla js … while they mostly use React today, we don’t know what the future holds for us. Which is why we want to be able to lazily load libraries once they are actually used.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

We use webpack 3.5.2

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:29
  • Comments:24 (2 by maintainers)

github_iconTop GitHub Comments

10reactions
divdavemcommented, May 31, 2018

This feature request would be useful, for example, to develop Grafana plugins. Grafana uses SystemJS (which is compatible with AMD) to load plugins. So, if I want to use Webpack to package a set of Grafana plugins (such as a Grafana App plugin), I need to have multiple entry points (one for each plugin), all of them in the AMD format (so that SystemJS can load them). But if they have common dependencies, I don’t want them to be duplicated in each entry point bundle… but if I use a common chunk, SystemJS currently does not know about it and will not wait for this chunk to be loaded before executing the loaded plugin. But if Webpack created this chunk in the AMD format and used AMD to load it, SystemJS would correctly wait for it to be loaded before executing the plugin that depends on it.

8reactions
ryxcommented, Jun 1, 2018

We are in the middle of migrating a requirejs-based application with custom bundling to a React SPA with webpack4. With AMD output we could load the split chunks through our old loader, too. That would make it incredibly more convenient to create a commons package holding our third party dependencies, while keeping our old module system in place until we are finished. So this would make webpack much more appealing to people coming from another loader.

Right now the only solution for us is to use one fat bundle for React/3rdParty and lose all advantages of dedicated bundling, unless we switch to webpack as loader (which is no option atm).

Read more comments on GitHub >

github_iconTop Results From Across the Web

Code Splitting - webpack
Entry Points: Manually split code using entry configuration. Prevent Duplication: Use Entry dependencies or SplitChunksPlugin to dedupe and split chunks.
Read more >
The 100% correct way to split your chunks with Webpack
Let's dive in. Bundle splitting. The idea behind bundle splitting is pretty simple. If you have one giant file, and change one line...
Read more >
Code splitting - What, When and Why - DEV Community ‍ ‍
WHAT to split, WHEN to split, and HOW to split. ... very flexible question - it is when to split, as well as...
Read more >
Code splitting with webpack and TypeScript - Spencer Miskoviak
If one feature's code is changed, only that code split chunk needs to be invalidated rather than all the code. Lastly, this results...
Read more >
reactjs - Code splitting causes chunks to fail to load after new ...
The following strategy works well for a React app, code split on ... I am using AsyncComponent HOC to lazy load chunks, and...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found