tooling.report

feature

Splitting modules between multiple entries

Can modules be split along their exports used by each entry bundle?

Person in shorts with blue hair walking left

The Test

This test checks to see if exports from a common module can be separated when they are used exclusively by different entry modules, avoiding a bundle being loaded that contains unused exports. In this particular variation, three entry modules each use one of two exported objects from a common module.

entry-1.js

import { foo } from './objects.js';
console.log(foo);

entry-2.js

import { bar } from './objects.js';
console.log(bar);

entry-3.js

import { bar } from './objects.js';
console.log(bar, '!');

objects.js

export const foo = { name: 'foo' };
export const bar = { name: 'bar' };

In this example, entry-1.js uses foo from objects.js, whereas entry-2.js and entry-3.js use bar.

Ideally this should result in 4 generated bundles: a bundle for entry-1 with foo inlined, and bundles for entry-2 and entry-3 that reference a separate bundle containing only bar.

Conclusion

browserify

Browserify's code-splitter, factor-bundle, will chunk out common dependencies but won’t split those dependencies even when possible.

parcel

Apart from the issues encountered in code-splitting/multi-entry, parcel does split out common dependencies above a certain size threshold, but does not split the dependencies themselves.

Issues

rollup

Rollup keeps foo and bar together in the same file.

Issues

webpack

Webpack extracts the common objects.js module as-is into its own shared bundle.