4

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?

Ben Carp
  • 24,214
  • 9
  • 60
  • 72
  • I don't get what you mean by "*when there is a strong connection between the tools*". The connection ([cohesion](https://en.wikipedia.org/wiki/Cohesion_(computer_science))) 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 Jan 09 '20 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 Jan 09 '20 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 autocomplete for available values. – Ben Carp Jan 09 '20 at 13:24

1 Answers1

3

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).

Inigo
  • 12,186
  • 5
  • 41
  • 70
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • Thanks, but editor's autocomplete won't recognize `styleUtilities` – Ben Carp Jan 09 '20 at 13:41
  • That sounds like a bug in your editor's autocomplete, then. What are you using? Does it not provide autocomplete on `import` statements either, or auto-import of undeclared variables? – Bergi Jan 09 '20 at 13:45
  • I'm talking about autoComplete on the fly. Using named import in any js/ts module I can type `some` which will suggest `someFunction` and `someFunction2`. In the second method I can typen `styleU` and it will suggest `styleUtilities`. What do you mean by autoComplete on import statements? – Ben Carp Jan 09 '20 at 13:53
  • Oh, I thought of real autocomplete that inspects types and knows what properties an object has, not just using similar identifiers in the same file. Such an autocomplete could also expand `import { someF… } from 'utilities';`. – Bergi Jan 09 '20 at 14:17