[Discussion] Named vs default exports about is-what HOT 2 CLOSED

I don't really see any argument that compels me to start using default exports. I like to streamline to just 1 thing way of doing things. More choices to achieve the same thing is never something that appeals me but just makes me worry about "what is the best way" while 9/10 this is useless worry. XD

So I just chose, there's nothing you can't do with named exports, so why not only use named exports. It's all about reducing options and streamlining, unifying, calming the mind. ;)

from is-what.

I am of the opinion that in an ESM world, default exports work well with single-export-per-file conventions.

Remove the ESM-only expectation and transpile to CJS and now you're dealing with the user expecting module.exports = thing but getting exports.default = thing which goes haywire very fast. 👈 This is actually a moot (for us) point since we are still going to named export everything, the internals are all ✨ magic transpiled and should match up regardless. It's the other-package imports that get tricksy.

Remove the single file requirement and bundle things into utils-and-more.ts and you want to know what you're importing.

As for the VS Code tooling support, watch this fancyness!

I get normal satisfactory autocomplete, same as named exports. This may be different or more complicated for CJS projects or other fancy stuff. Default exports do have some hiccups, this is true! Take this:

// Hello.ts
type Hello = string
export type { Hello as default }

☝ You can't type Hello and hit Enter and have it auto-import the default Hello. I don't know if this is a export type problem or a as default problem or what. I just know that this is the only time that I've had issues. 😃 But yes, there are occasional hitches with auto-importing.

from is-what.