JavaScript - Does the use of namespace imports have an effect on a module's treeshake-ability?

Question

Original question:JavaScript - Does the use of namespace imports have an effect on a module's treeshake-ability?

Assume that we are using ES6 module system. According to the docs, when we use an * as Alias import, we are taking all of the exports from the file and containing them inside of an object of the alias's name.

I am wondering if this has any impact on the tree-shakeability of the imported module?

If so, are named and default imports better in that regard?

Lathy

Does #45736034 answer your question (despite not being an exact duplicate)? – Serafinaserafine

Depends what you are doing with them. If you try to enumerate the properties of the namespace object or something like, all exports will be have to be loaded of course. But that doesn't mean default-exporting an object is any better… – Serafinaserafine

@Bergi, I'm not doing anything non-standard with them, just importing and using as normal. – Lathy

@Bergi, I tried to use this tool: babeljs.io/repl/… and I found that these had identical outputs: import * as React from 'react'; import React, {useConst} from 'react'; but other styles did not. – Lathy

That would be a special case where react default-exports their module namespace object. Not all modules do this (and tbh, it's a bit weird) – Serafinaserafine

Answer 1

In theory, it does not. In practice, it may affect the tree shaking.

In theory, it should not impact because bundler should be able to find the usage patterns and do the tree shaking.

But in practice, there are two challenges. The first one is the problem of call site, e.g.:

import { resultOfSomeCalculation } from './other.js';
import * as all from './all.js';

const key = resultOfSomeCalculation();


export function getData() {
  return all[key]();
}

In this example, the bundle cannot figure out statically i.e. at compile time which function will be called and thus it ends up bundling everything together.

The second challenge is the implementation of the bundler itself. When you have multiple nested namespaced imports coupled with barrel exports, it quickly spirals out of hands. There are so many edge cases. It works for simpler cases but not for these deeply nested imports.

Thus, there are limitations to tree shaking with namespaced imports. And on a side note, do not avoid namespaced imports just for the sake of tree shaking. Tree shaking is optimization goal and not the end result. If it makes code readable, feel free to use namespace imports.

Melo

What do you mean by "multiple nested namespaced imports coupled with barrel exports"? Yes, one probably should not export a namespace object either as that makes usage analysis impossible – Serafinaserafine

@Serafinaserafine what you said - one should not export a namespace object - I have seen barrel exports which simply re-export namespace object which in turn themselves re-export other namespace objects. – Melo