Wildcard or asterisk (*) vs named or selective import es6 javascript

Question

Just wondering which one is the best way to use import:

import * as Foo from './foo';

VS:

import { bar, bar2, bar3 } from './foo';

In terms of efficiency, say for example, I'm using webpack for bundling all the JavaScript files. Will the first one actually importing everything even though I'm not using them in the main code?

Some references that I can find are:

In Airbnb style guide, they are recommending no wildcard so there will always be default import object, and this.

possible duplicate of [Is using an ES6 import to load specific names faster than importing a namespace?](https://stackoverflow.com/q/45735534/1048572) — Bergi, Feb 21 '19 at 09:43

score 46 · Accepted Answer · edited May 21 '23 at 23:50

46

If you use webpack with the dead code elimination provided by the new uglify, or rollupjs with tree-shaking, then the unused imports will be stripped.

I partially agree with the airbnb styleguide to not to use wildcard imports, although javascripts wildcard imports do not suffer from the same diseases as for example pythons or javas wildcard imports, namely it does not pollute the scope with variable names defined in other modules (you can only access them by moduleB.foo, not foo when using import * as moduleB from ...).

About the article on testing: I kind of understand the concerns, but I see nothing that cannot be solved there. You can mock the imports themselves with some custom module loader (a custom amd module loader is literally 15 lines of code), so you dont have to mess with the local scope of the tested module.

edited May 21 '23 at 23:50

ggorlen

44,755
7
76
106

answered Feb 05 '17 at 11:43

Tamas Hegedus

28,755
12
63
97

2

if I `import * as Foo from './foo'`, and I use only `Foo.bar`, will `Foo.bar2` and `Foo.bar3` be eliminated as dead code? – brietsparks Oct 23 '18 at 15:41
3

@bsapaka Yes, if `Foo.bar2` and `Foo.bar3` are not used at all. – Tamas Hegedus Oct 23 '18 at 16:10
6

Where can I read more about this? For example official docs or github issue threads. – Jason Kuhrt Oct 26 '18 at 01:21

score 37 · Answer 2 · answered Oct 13 '17 at 03:24

Concerning this part of the question :

Will the first one actually importing everything even though I'm not using them in the main code?

Here's how it gets compiled with Babel 6.26:

Named

import { bar, bar2, bar3 } from './foo';

... becomes ...

'use strict';

var _foo = require('./foo');

Wildcard

import * as Foo from './foo';

... becomes ...

'use strict';

var _foo = require('./foo');

var Foo = _interopRequireWildcard(_foo);

function _interopRequireWildcard(obj) { 
    if (obj && obj.__esModule) { 
        return obj;
    } else {
        var newObj = {}; 
        if (obj != null) { 
            for (var key in obj) { 
                if (Object.prototype.hasOwnProperty.call(obj, key))
                    newObj[key] = obj[key];
            }
        }
        newObj.default = obj; 
        return newObj;
    }
}

In both cases the whole file is imported through require.

With wildcards imports, an _interopRequireWildcard function is defined and used to assign all exports to the namespace variable.

It's worth noting that compiled code will only contain a single _interopRequireWildcard definition, and one call to require and _interopRequireWildcard for each import.

Ultimately, the use of wildcard imports will involve a bit more processing at run-time and cause a slight increase in size for the compiled js.

Would be great to see if this holds true for webpack 4 with its tree-shaking feature — Kostiantyn Ko, Sep 12 '18 at 13:24
The overhead is in babel, there is no overhead if you use rollupjs. — Tamas Hegedus, Jul 13 '21 at 11:41

score 11 · Answer 3 · answered Jun 08 '18 at 19:41

Since, with a modern WebPack setup, the two will generate the same compiled/transpiled JS, the real value in named imports is how much more expressive it is. By naming your imports you are telling any one that opens the file which functions from a module you are going to use. An example of where this can be helpful is when writing tests, if mocking is necessary, you have an explicit list of imports to mock.

score 8 · Answer 4 · answered Feb 05 '17 at 12:05

I agree with @Tamas.
If you require the full access to all exports in the target file, then you can use the import * as Foo from './foo'; or import foo from './foo':

but if you need to use specific function or const then better avoid "import *" and be explicit what you needs to do.

Wildcard or asterisk (*) vs named or selective import es6 javascript

4 Answers4

Named

Wildcard

Linked

Related