imports/prefer-default-export idiomatic use

hi,

how is the case where a file grows from containing only 1 function to containing 2 handled best?

example:

let’s say i have a file called window.js, which contains only one function, showWindow(). it’s imported as import { showWindow } from 'window'.

of course this goes against imports/prefer-default-export. how should this be fixed? i guess i move the code to window/showWindow.js.

if i do that, then my import becomes import showWindow from 'window/showWindow'. now what happens when a want to create another function, countWindows() ?

2 possibilities:

A. i move showWindow back to window.js and add countWindows there. if i do this, now i have to find all the places that imports showWindow and change those imports.

B. i create another file called window/countWindows.js and put the function there. if i do this, it means that nearly all my files will only contain 1 function.

so i wonder, how does airbnb handle this?

[ljharb]

@tleunen that’s potentially a fine way to go also - it really depends on the use case.

I’m suggesting that the default be one function default exported per file - and that if you think carefully about a use case, and you need multiple exports, then great! Make an exception.

The point of the defaults is so that you have to think about if and why you deviate - not that you can never deviate.

[ljharb]

Yes, it should disable named exports - the problem is that named exports make sense for a few specific use cases, like reducers, action_creators, constants, exporting a wrapped HOC for testing, etc - and a rule that prevented all named exports would be too restrictive.

We try to make the linter cover as much as possible, but there are times when you do still have to read the guide and apply human judgement 😃