import Foo from "./foo" What if, inside foo.js you rename class Foo to class Bar Old imports will still work w/ old name: they no like
-
-
The diff is being forced to "do it right by default", rather then being forced to think about + needing lint rules to check you did right
-
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.
- 3 more replies
New conversation -
-
-
import extend from "lodash.assign"? If it's just that you'd like that to be discouraged, lint it away. You probably want to avoid ...
-
export function assign from a file named extend in the named-exports-only style too (if it's the only export).
End of conversation
New conversation -
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.