Avoid using default exports (2024)

Rense Bakker

• Jan 11

Actually IDEs should not have any problem finding your default exports aslong as they are not anonymous functions or objects. If you use recommended eslint rules, it will tell you not to export anonymous functions and objects.

// Editor has no idea what to doexport default function(){}// Editor will be able to auto import doSomething export default function doSomething(){}

𒎏Wii 🏳️‍⚧️

• Jan 11

Default exports can be confusing in complex modules. Developers may not know which export is the default or even be aware of its existence. This can cause delays as engineers must spend more time looking at documentation or even the source code to find the functions they need.

I've read this paragraph several times now and I still think it makes no sense whatsoever. Can you explain what you mean by this?

If you decide to rename a named export in a module, for example, changing the name of the add function to sum, most IDEs can automatically update all usages. This makes the refactoring process much easier.
However, with default exports, this isn't possible.

Again, this doesn't make any sense to me whatsoever; what is the problem here? Default exports have no name, so what would you want to happen here?

As we discussed earlier, when a module provides named exports, we can easily select a specific function from the module by using a shortcut provided by the IDE. This feature not only saves time, but also helps the IDE suggest and auto-import the necessary functions as we type.

This one makes more sense, but it's not really an argument against default imports. As long as your default export is also available as a named export (which is probably a good idea regardless), this still works 100%.

Default exports can be imported using any name you choose. This can lead to inconsistencies when multiple engineers are working on the same codebase and using different import names.

Again, this is a good reason to also have a named export for your default export, but it doesn't speak against having a default export in any way.

Setting that aside, regardless of consistency or not, if I look at a source file and see import add from "sum" I will probably scratch my head multiple times and tell whomever wrote that to fix it (or just not interact with the project if it's OSS)

Conclusion

Just provide named alternatives for your default export and everyone will be happy. We can have both.

Anass Boutaline

• Jan 12

Hauke T.

• Jan 12

Eric B

• Jan 12

Sean Dinan

• Jan 11 • Edited on Jan 11 • Edited

Yep, spot on. Especially the Inconsistent Codebases section.

In the rare instances where a named export does need to be renamed, it can always be done with as:

import { Provider as RollbarProvider, ErrorBoundary } from '@rollbar/react';

José Pablo Ramírez Vargas

• Jan 11

The IDE has no issues finding default exports while typing. It is a matter of providing proper information. Someone already said that if you export a nameless something, then that's a problem, but if you export something with a name, that name shows up in autocomplete.

Furthermore, NPM packages should provide proper d.ts files. Using my vite-plugin-single-spa package as example, you just install, then open vite.config.ts and you start typing "import vitep". At this point you should see autocomplete showing you the right option (vitePluginSingleSpa).

Drew Killeen

• Jan 20

Good thoughts, I like that you're challenging convention and asking us to think through things rather than just following the norms.

In my opinion, all of what you're saying is true when a file has multiple exports. I do find it confusing to have a default export mixed with named exports. But typically when a default export is used, I only see a single export from that file. I haven't run into any problems with that, especially since the file, function, and import almost always share the same name.

But at the same time, I also see no argument against using only named exports, so maybe you're on to something.

Jack

• Jan 16

This is the developer-equivalence of first world problems.

IDEs have no problem discovering default exports in my experience. And I frequently rename default exports and vscode is smart enough to rename imports automatically.

I also have absolutely no issue with somebody deciding to only use named exports in their codebases, go for it. But here we're dressing personal preference as best practice which is incorrect.

Shawn P

• Jan 12 • Edited on Jan 12 • Edited

The reason we have so many different tools at our disposal is so that we can use the best tool for a given context, and contexts vary greatly in this field. It is disappointing to see so much of these “never use X conventional method ever again” articles and videos which usually fail to sufficiently acknowledge the optimal use cases for the thing they are bashing on and seem aimed at being provocative and generating clicks more than offering genuine educational content. This article starts by acknowledging the correct use cases but then proceeds to suggest never using them ever again.

Default exports are absolutely the right choice when there’s only one thing to be exported, and there are plenty of architectural nuances from project-to-project that could warrant their use in other contexts. This point-blank statement of “default exports are bad and you shouldn’t use them” comes across as biased and imho could be potentially misleading to beginners.

Матвей Т

• Jan 13

A thing I tend to do, when I am working on a module where it makes sense to have multiple exports, but also one main default export is this:

export function add(x: number, y: number): number { return x + y;}export default add;

Joao Sumbo (J.P)

• Jan 13 • Edited on Jan 13 • Edited

Paul Fox

• Mar 1

I have worked on code bases with default exports where casing and typos have caused discoverability issues.

import Buton from 'Button'

If it can break "find in files" that's a good enough reason for me to not use it. IDEs make our lives easier in a lot of ways, but at the end of the day an IDE is just a tool. If you need it to understand your code, there's a problem. Anything that makes the code easier to understand without tooling is best practice in my book.

Default exports are not needed. Exporting a single named function from a module is completely unrestricted. If you need to rename a module, use the as directive.

import { module as betterNamedModule } from 'module';

Then grepping the codebase will at least see the import reference. You won't even need it if you take your time namig things and refactor when things become so similar that their names overlap. So why use default exports?

Alois Sečkár

• Jan 11

Good summary.

I especially dont like when I am forced to mix named and default imports from 3rd party libraries. (yes, I know I can make a custom reexport somewhere in codebase).

Dimitar

• Jan 13

If you're getting confused by exports then I'd recommend investing a few minutes in getting a free IDE.

As a newcommer to the JS env from cpp/python I don't really see the need of default exports. Everyone else has managed without them.