Named exports instead of default export?

[fisker]

For better tree-shaking.

[sindresorhus]

I don't see how that matters in this case as it's for Node.js, not browsers.

[Qix-]

Bundling for the desktop is valid, especially in end-user applications. I'd be :+1: for this if @sindresorhus also agreed and if someone did a PR.

[fisker]

I need to bundle this package, and I only want use clearScreen.

[sindresorhus]

I'm neutral about it. Many of the exports have too general names when imported without the namespace though. ansiEscapes.image() makes it clear what it is, but image() could be anything.

[Qix-]

For those users we'd just rec using import * as ansiEscapes from 'ansi-escapes'. I would imagine in some cases the bundler would still be able to do DCR even then.

[sindresorhus]

@Qix- It's not just image(). It applies to most of the exports.

[Qix-]

I don't see how that negates what I said though. You can still import as a namespace. It's up to users to use proper naming. If they just want to import image then they should import { image as ansiImage } from 'ansi-escapes' if they want it to be clean.

My point was more that even using a wildcard import (import * as ansiEscapes) might still allow the bundlers/compilers to do dead code removal ("tree shaking" as the JS community seems to call it) even though it's done via indirection.

[privatenumber]

@sindresorhus Would you be open to a PR?

I think the argument for export names not being self-descriptive without the context of the package name applies to most ESM packages, including native ones:

// both `access` and `constants` are very vague without knowing it comes from `fs`
import { access, constants } from 'node:fs/promises';

[sindresorhus]

Would you be open to a PR?

Yes, but it should preserve the default export too (can be done with re-exporting). Most users don't care about tree-shaking this, so the main docs should remain the default export too. It can be a tip mention in the docs that this can also be imported using named imports.

I think the argument for export names not being self-descriptive without the context of the package name applies to most ESM packages, including native ones:

Node.js APIs are not very good, so I wouldn't use that as an example of great API design.