-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discussion] Named vs default exports #60
Comments
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 Remove the single file requirement and bundle things into As for the VS Code tooling support, watch this fancyness! ezgif-3-91f82fb675.mp4I 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 |
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. ;) |
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:
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 #57 (comment)
The text was updated successfully, but these errors were encountered: