search

springernature / eslint-config-springernature

ESLint shareable config used at Springer Nature
MIT License
3 stars 0 forks source link

Remove prefer-default-export #34

Closed joeyciechanowicz closed 5 years ago

joeyciechanowicz commented 5 years ago

Currently the @springernature/eslint rules (from the AirBnB rules) specify that we should prefer a default export such as

default export someThing

There is some argument against requiring a file to have a default export: https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/

There is an issue on the AirBnB rules repo around this issue: airbnb/javascript#1365

For me, named exports play nicer with IDE's and you should be able to treeshake just fine. This comment sums up my opinion pretty well:

Isn't this the problem? If developers are not aware of how treeshaking works, the temptation to resolve the lint warning when exporting multiple functions from within one file is to export a single object with all the named exports as members. This makes the linting error go away, but it prevents treeshaking, so it's actually encouraging a practice that could lead to poorer performance. Surely the treeshaking argument alone is enough to encourage all exports to be named exports?

Relevant OpenSpace discussion can be found here: https://github.com/springernature/frontend-open-space/issues/217

Implementation note Removing the rule completely stops it being enforced, rather than disabling it explicitly in the configuration.