Why Top Frontend Teams Ban `export default` and Prefer Named Exports

Background

In the JavaScript ES module system export default lets a module expose a single value or function that can be imported with any identifier. Example:

// MyComponent.js
export default function MyComponent() {
  // ...
}

// App.js
import MyAwesomeComponent from './MyComponent.js'; // import name is arbitrary

Although concise, many large‑scale front‑end teams and open‑source projects (e.g., Google, Airbnb, Vant) forbid or discourage export default in their style guides. The restriction is driven by concrete maintenance and tooling concerns rather than pure aesthetics.

Naming consistency

Because the importer can choose any name, the same component may appear under many different identifiers across a codebase, making it hard to trace usage and refactor safely.

Named exports enforce a single source of truth for the identifier:

import { MyComponent } from './MyComponent.js'; // name is fixed
import { MyComponent as MyAwesomeComponent } from './MyComponent.js'; // explicit rename

This guarantees that MyComponent always refers to the same entity, which improves readability and collaboration.

Tree‑shaking support

Modern bundlers (Webpack, Rollup, Vite, etc.) rely on static analysis to eliminate dead code. Named exports produce an explicit dependency graph, allowing tools to detect unused exports more reliably and generate smaller bundles. While bundlers have become smarter about export default, named exports still give a clearer static picture.

Simplifying barrel re‑exports

Component libraries often use an index.js “barrel file” to re‑export sub‑modules. With named exports the pattern is trivial:

export * from './Button';
export * from './Card';

If the underlying modules use export default, the barrel file requires additional boilerplate:

export { default as Button } from './Button';
export { default as Card } from './Card';

The extra syntax defeats the purpose of a clean barrel file and adds maintenance overhead.

When export default is acceptable

If a file truly contains a single logical export—such as a configuration object, a constant, or a small utility whose entire purpose is that export—using export default can be reasonable.

Practical trade‑offs

Choosing between default and named exports is a trade‑off:

Default export : concise syntax, but permits arbitrary import names, which can lead to inconsistency, harder refactoring, and less transparent APIs.

Named export : enforces a stable identifier, improves tree‑shaking, and simplifies barrel re‑exports, at the cost of a slightly longer import statement.

For large, long‑living projects the benefits of named exports usually outweigh the syntactic convenience of export default. Embracing named exports leads to a more robust, clearer, and tool‑friendly code ecosystem.