funcs.js

export function hello() {
  echo 'foo'
}

export function foo() {
  echo 'bar'
}

index.js

import * as Funcs from './funcs.js' // import module, does tree-shaking work?
import { hello } from './funcs.js' // optimise imports, potentially clashes with other imports
import { hello } as Funcs from './funcs.js' // what should make sense, but isn't supported syntax

// this should be straight forward... 
Funcs.hello()

// vs having some random function on top level scope
hello()

// and this shouldn't work if I didn't import it
Funcs.foo()

That's my question. Does it make any difference to tree-shaking if I'm using form 1 vs form 2. Form 2 is preferable for expressiveness, but form 1 is the only way I can get everything into a module/namespace. Form 3 would be my suggestion, but maybe I don't know something that someone hasn't already argued against why this shouldn't be supported.

I have no idea where to go suggest this, or even to build a babel plugin to do this.

Edit: for context, I'm working with some newer libraries (rxjs) that don't expose default exports, and rely on developers to load all the functions they need. So I don't have control over those exports.

Edit: a workaround that was suggested was to simply create a global import file that imports all the globally required imports, and exports it all as a module, so that's what I'm doing for now.

Edit: found es-discuss. Will go there instead to forward discussion hopefully.

Edit: most enlightening discussion found here.

funcs.js

export function hello() {
  echo 'foo'
}

export function foo() {
  echo 'bar'
}

index.js

import * as Funcs from './funcs.js' // import module, does tree-shaking work?
import { hello } from './funcs.js' // optimise imports, potentially clashes with other imports
import { hello } as Funcs from './funcs.js' // what should make sense, but isn't supported syntax

// this should be straight forward... 
Funcs.hello()

// vs having some random function on top level scope
hello()

// and this shouldn't work if I didn't import it
Funcs.foo()

That's my question. Does it make any difference to tree-shaking if I'm using form 1 vs form 2. Form 2 is preferable for expressiveness, but form 1 is the only way I can get everything into a module/namespace. Form 3 would be my suggestion, but maybe I don't know something that someone hasn't already argued against why this shouldn't be supported.

I have no idea where to go suggest this, or even to build a babel plugin to do this.

Edit: for context, I'm working with some newer libraries (rxjs) that don't expose default exports, and rely on developers to load all the functions they need. So I don't have control over those exports.

Edit: a workaround that was suggested was to simply create a global import file that imports all the globally required imports, and exports it all as a module, so that's what I'm doing for now.

Edit: found es-discuss. Will go there instead to forward discussion hopefully.

https://esdiscuss/topic/syntax-to-pick-named-exports-from-a-module

https://esdiscuss/topic/proposal-importing-selected-chucks-of-a-module-into-an-object

Edit: most enlightening discussion found here.

https://esdiscuss/topic/import-foo-bar-as-obj-from-module

• javascript
• typescript
• ecmascript-6
• es6-modules

3 Answers 3

Turns out I'm not the only one who has had this thought. This thread goes into more detail about some of the potential issues associated with this syntax... I don't necessarily agree but that's how it is.

https://esdiscuss/topic/import-foo-bar-as-obj-from-module

For form 3, couldn't you just do import { hello as Funcs } from './funcs.js'?

Form 2 will benefit from tree shaking. import * means you dont want tree shaking and want to import everything. So webpack will do so.