I've come into an argument with my co-workers for which we can't seem to find an answer from any official source (MDN, webpack documentation, ...). My research hasn't yielded much either. There seems to be doubt even when it comes to importing as well.

Our setup is Webpack, Babel, and a typical React / Redux app. Take this example:

export * from './actions';
export * from './selectors';
export * from './reducer';

export { default } from './reducer';

This allows me to separate a Redux module into logical sections, making the code easier to read and maintain.

However, it is believed by some of my co-workers that export * from may, in fact, harm webpack's tree-shaking capabilities, by tricking it into believing an export is used when it is in fact just being re-exported.

So my question is, are there any facts proving or disproving this?

I've come into an argument with my co-workers for which we can't seem to find an answer from any official source (MDN, webpack documentation, ...). My research hasn't yielded much either. There seems to be doubt even when it comes to importing as well.

Our setup is Webpack, Babel, and a typical React / Redux app. Take this example:

export * from './actions';
export * from './selectors';
export * from './reducer';

export { default } from './reducer';

This allows me to separate a Redux module into logical sections, making the code easier to read and maintain.

However, it is believed by some of my co-workers that export * from may, in fact, harm webpack's tree-shaking capabilities, by tricking it into believing an export is used when it is in fact just being re-exported.

So my question is, are there any facts proving or disproving this?

• javascript
• webpack
• ecmascript-6
• es6-modules
• tree-shaking

• 2 Why don't you just set up a dummy project and try it? I realize that's not as authoritative as actual documentation from the rollup team, but it ain't nuthin. – Jared Smith Commented Feb 20, 2019 at 19:11
• github.com/webpack/webpack/issues ... Seriously, with open source stuff sometimes the best place to ask is at the repo... – Heretic Monkey Commented Feb 20, 2019 at 22:16
• @Bergi All of those relate to importing. I'm specifically asking about re-exporting using export * from './module' which is a different thing. – pbondoer Commented Feb 21, 2019 at 8:19
• @pbondoer Ooops, you're right, I totally confused the syntax with a namespace import where the tree-shaking optimisation is less trivial. – Bergi Commented Feb 21, 2019 at 9:41
• @HereticMonkey A link to an index page (that is guaranteed to change over time) was the last thing I needed to read. – Romain Vincent Commented Nov 13, 2021 at 19:36

1 Answer 1

It is believed that export * from may harm webpack's tree-shaking capabilities, by tricking it into believing an export is used when it is in fact just being re-exported.

No, import/export declarations don't do anything but set up an alias to the exported variable, they do not count as a "use". Given their semantics, they are tracked specially by any bundler and will not adversely affect tree-shaking.

Not even a properly done renamed alias will break that:

export { X as Y } from '…';

import { X as Y } from '…';
export { Y }

import { X } from '…';
export { X as Y }

but usage in a statement would count as usage and break (non-sophisticated) optimisations:

import { X } from '…';
export const Y = X; // avoid!

So my question is, are there any facts proving or disproving this?

You can just try it out and see it work.