When designing an ES module's public surface, what are the practical tradeoffs between exposing values as named exports versus a single default export?

## The decision, stated precisely Both forms put a value in a module's export table; the only real difference is **who owns the name**. A named export fixes it at the source. A default export leaves it blank and lets every consumer fill it in. Every tradeoff below is a consequence of that single asymmetry. ## What named exports buy **Consistency.** `import { Button } from './button.js'` must spell `Button`. Ten importers therefore agree on the identifier, which makes code reviews, conversations and search all line up on one word. **Searchability.** Grepping for a named export finds its declaration and every import of it. With a default, the source declares one name and the importers may use any other, so text search only ever finds part of the picture. **Refactorability.** Editor rename operations follow the export entry. Rename a named export and every importing site updates. Rename the local variable behind a default export and nothing downstream changes, because nothing downstream referred to that name. **Failure at link time on typos.** A misspelled named import cannot be resolved and is reported before the module runs. A default import always resolves as long as the module has *any* default, so a consumer who grabbed the wrong file gets a value, just not the one they meant. ## What default exports buy **A single obvious artifact.** For a file whose entire reason to exist is one class, one component or one configuration object, `export default` says so. There is no second export to wonder about, and no repetition of the name in the declaration, the export clause and the import. **Consumer-side freedom.** When two dependencies both export something called `Client`, a default import lets each consumer disambiguate at the import site without an `as` clause. With named exports the same thing is achievable — `import { Client as StripeClient }` — but it is a keystroke or two more. **Terse authorship.** `export default function () {}` needs no name at all. That convenience is also its trap: the spec gives such an anonymous function the name `default`, so it shows up as `default` in stack traces and `Function.prototype.name`, which is worse for debugging than a real name. Writing `export default function log() {}` restores the name. ```js export default () => {}; // the exported arrow's .name is "default", not "" ``` ## The naming-drift cost in practice The cost of a default export is rarely visible on day one; it accumulates. A widely used component acquires three or four aliases across a large codebase. Someone renames the file, the local declaration and the concept, and the old name survives in every consumer because nothing ever forced it to change. New joiners search for the current name and miss half the call sites. None of this is a bug, and none of it is caught by a test — which is exactly why it is a convention question rather than a correctness question. ## Mixing both A module may have a default *and* named exports, and doing so is legal and common. The price is that consumers must use two import shapes for one file — `import Button, { SIZES } from './button.js'` — and that barrel re-exports become inconsistent, because `export * from` forwards the named exports but skips the default. If a package's barrel is the intended entry point, a named-only surface removes an entire class of forwarding special cases. ## A workable policy Most teams that have had this argument land somewhere near: named exports for shared libraries, utilities and anything a barrel forwards; a default reserved for files that are genuinely one artifact and are imported directly. Whatever you pick, encode it as a lint rule so it holds when the team grows — a convention enforced only in review erodes at exactly the rate people stop reviewing carefully. Also state the rule for the awkward middle: a module that today has one export but will plausibly grow a second is better off named from the start, because adding a named export beside an existing default is an ergonomic downgrade for every consumer. ## Answering this in an interview Lead with the ownership asymmetry — the author names it versus the consumer names it — then give two concrete consequences on each side, then say what rule you would actually enforce and how. An answer that is only "defaults are bad" is weaker than one that says *why* the naming decision matters, and names the case where a default still earns its place.