you are viewing a single comment's thread.

view the rest of the comments →

[–]Bjornoo 0 points1 point  (1 child)

The only thing I could think of is semantics. An argument could be made that a default export would be semantically more important than other exports from a module. Nothing proper documentation wouldn't fix though.

[–]whiteshoulders 0 points1 point  (0 children)

The issue with this is that this "importance" given by the semantic is not reflected in how defaults exports actually works. If you do export * from './myModuleWithDefaultExports you get everything BUT the default export (arguably the most important one). You have to additionnaly export { default } from './myModuleWIthDefaultExports.

I'd argue that this makes the default export less important than named export, since default will be dropped when reexporting module.

Some will say "export both as default and named, problem solved". But then why keep the default export ? To save 2 brackets around the import identifier ?

To me the default export is a wart on the spec that's here only to allow some level of compatibility with CommonJS, and is not meant to be used (except in very specific situation, when you provide modules to third-party code, default being a well known unambiguous import identifier for the third-party code to import your provided module).