Exactly - they dislike that export default class Foo can be imported with a different name, ie import Fooooo from "./foo"
I don't think you're counting all the costs correctly. In a non-default world, the module has to come up with a name.
-
-
I also don't think this hazard is what you're implying. I've written huge JS module codebases for years and the first thing I do...
-
...when I want to know what a name is is to ask vscode to jump to the import. Named or default doesn't make that much difference ...
-
No I didn't want to imply the difference is huge ;-). Just don't see any value in consumer provided names, except when there are collisions
-
I think consumers should probably use the same name as the module as a general rule, but don't think it's that important that they're unique
-
Module names should be globally unique, names inside of them are always 100% resolvable locally so I don't see the big deal.
-
I think you're undercounting programming styles where nearly all modules have a default export and nothing else.
-
That might be true. I'm on huge TS stuff, where most modules also expose at least some interfaces around the main export
-
I've written nearly 100% TS modules for at least 2 years. I think when there is one JS export + interfaces default export is more valuable
- 1 more reply
New conversation -
-
-
Otherwise the consumer (always). Which is worse? Imho.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.