For utility functions and consts I usually use named exports.

//utilities.js
export function someFunction(param){...}
export function someFunction2(param){...}


//someModule.js
import {someFunction} from "./utilities.js" 

But sometimes, I export them as the default object.

//styleUtilities.js
export function someFunction(param){...}
export function someFunction2(param){...}
export default {someFunction, someFunction2}

//someModule.js
import styleUtilities from "./styleUtilities" 

const {someFunction} = styleUtilities

When exporting as default object, does it disrupt tree shaking for unused values in Webpack?

For utility functions and consts I usually use named exports.

//utilities.js
export function someFunction(param){...}
export function someFunction2(param){...}


//someModule.js
import {someFunction} from "./utilities.js" 

But sometimes, I export them as the default object.

//styleUtilities.js
export function someFunction(param){...}
export function someFunction2(param){...}
export default {someFunction, someFunction2}

//someModule.js
import styleUtilities from "./styleUtilities" 

const {someFunction} = styleUtilities

When exporting as default object, does it disrupt tree shaking for unused values in Webpack?

• javascript
• node.js
• webpack

• I don't get what you mean by "when there is a strong connection between the tools". The connection (cohesion) between them is why they are placed in the same module in the first place? What's the point of putting them in an object? – Bergi Commented Jan 9, 2020 at 12:43
• "When exporting as object, does it disrupt tree shaking for unused values in Webpack?" - Yes. If all you want is having a styleUtilities name in the importing module, use named exports and import * as styleUtilities from "./styleUtilities". – Bergi Commented Jan 9, 2020 at 12:44
• @Bergi, It provides order. Naming can use different conventions. When I'm looking for a certain tool, I usually don't remember it's exact name. It could be convenient to remember that all style utilities are under styleUtilities, and then just type styleUtilities and enjoy autoplete for available values. – Ben Carp Commented Jan 9, 2020 at 13:24

1 Answer 1

When exporting as default object, does it disrupt tree shaking for unused values in Webpack?

Yes.

It could be convenient to remember that all style utilities are under styleUtilities.

For that, you should still be using named exports in your utilities.js module. Then when importing that module in someModule.js, use namespace import syntax:

import * as styleUtilities from "./utilities.js";

styleUtilities.someFunction();

This will still allow tree-shaking, and offer the choice of import style to the consumer of your module (not forcing an object upon them).