question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

What is the benefit of prefer-default-export?

See original GitHub issue

The docs don’t have a Why section for prefer-default-export, and I’m not seeing the benefit of it on my own. I would think that not using default is preferred. With default exports, you lose refactoring power (if you rename the source const/function/class, it won’t rename default imports).

As more of an edge case: it makes code less future-proof. i.e. if you create a file that will be a collection of errors, but it only starts with one error, to follow the linting rules, you’ll have to have it export default, but then when you add the 2nd error at a later time, you’ll have to do a bunch of refactoring that could have been prevented if the recommendation was to avoid default export.

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:335
  • Comments:167 (8 by maintainers)

github_iconTop GitHub Comments

147reactions
ljharbcommented, Apr 10, 2017

For your edge case: that can totally happen, but that’s the case for an eslint override comment, which is an explicit indicator that this single-export file is intended to be a multiple-export file.

Given that - that you’d basically never have to change a default export to a named export - the refactoring power is all in the filename. Meaning, you a) change the filename and rename all the imports (importjs can do this for you; eslint-plugin-import will ensure you didn’t miss any); b) renaming any of the code in the file does not change how consumers import it; whereas with named exports, the name in the code is tightly coupled to the name that it’s being imported by; c) this rule encourages more files that only ever export one thing, as the default, which is better for readability, maintainability, treeshaking, conceptual understanding, etc.

104reactions
ljharbcommented, Dec 13, 2017

@ha404 it’s a ridiculous argument, because you can rename named imports as you bring them in, and you can typo those too. Refactoring is identically easy with default and named exports with respect to the names of the imported variable. Separately, it’s a feature that with default exports, everyone can more easily import it as their own name. If you want consistency with import names in your project, use a linter to enforce that - don’t change your module architecture to try to enforce that, especially when you can’t even force it that way.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Prefer default or named exports? : r/typescript
It's not only a preference. Named exports can't be as easily renamed and treeshake better naturally. Those alone are two very good reasons....
Read more >
Default exports vs. named exports | by Sean Baines - Medium
With ES modules, there are 2 ways to export a module: default exports, and named exports. As a quick reminder, a default export...
Read more >
Prefer default export eslint error
When there is only a single export from a module, prefer using default export over named export. class HomePage extends Component { //....
Read more >
JS: Export vs Export Default | Matt Shelley
According to the MDN web docs, default exports are useful “to export a single value or to have a have a fallback value...
Read more >
Change: Prefer default export to no default export (#20) · Issues
We can leverage native language early-throws and editor tooling to give better hints. Default exports don't throw an error if not present until ......
Read more >

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found