[Discussion] Named vs default exports

[jcbhmr]

More discussion on the pros and cons of default exports vs named exports has been discussed to death in https://github.com/airbnb/javascript/issues/1365 where Airbnb explains why they use default exports

it's a bit much to parse through. I am not seeing where exactly AirBnB's reasoning is in this thread. But a quick glance and this caught my eye:

• Named exports make it clear throughout the application that you are using a specific value. Using default exports means that each part of the app may have a different name for the same function which makes code harder to reason about.
• The argument about changing the name requiring all other parts of the application needing to do the same WAS VALID at one point, but with features like Rename Symbol which most IDE's - and VSCode (which lets be real most of us are using) have -- this became 100% useless.
• Named exports make things like Auto Imports that some language features such as TypeScript support. Without named exports, they are far more prone to issue and require context before they are ever capable of suggesting an auto import of a given value.
• If you end up needing to export more values from a file as the application grows, it ends up becoming quite messy to either change from default to named as this rule seems to want -- or move to more files being used. With the more files approach - if you want to keep things logically organized that may even mean you have to move things into a folder and make significant changes to the design of the project as it grows and can end up highly disorganized Whereas if you default to named exports then nothing changes, you simply export more values. If you want to use folder approach, you can - just do the folder, create an index file and export named exports from that - and dependent files have no knowledge of the change required.

This is kinda where I'm at. This and also all of the issues I've had in the past. Literally 10+ hours wasted in tooling hell and it all went away by using named exports.

Originally posted by @mesqueeb in https://github.com/mesqueeb/is-what/issues/57#issuecomment-1574661177

[jcbhmr]

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!

https://github.com/mesqueeb/is-what/assets/61068799/29920a47-4d6b-4b0c-a590-40f06093e8d4

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.

[mesqueeb]

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. ;)