Sounds overly fussy given TS only cares about class interfaces rather than class names.
-
-
-
Replying to @wycats @robpalmer2 and
It's about name consistency (even after rename) in large code base / teams, don't call same thing Buffer in one file and Blob in another
1 reply 0 retweets 1 like -
Replying to @mweststrate @wycats and
There is still the flexibility to give other name; use 'as', which makes it very clear to reader that you are doing this
2 replies 0 retweets 1 like -
Replying to @mweststrate @wycats and
So, Joe, its just about calling lodash.extend not suddenly assign and increasing the cognitive overhead for reader (and writer)
1 reply 0 retweets 0 likes -
Replying to @mweststrate @robpalmer2 and
1: import extend from "extend" is enough convention (and is lintable) to get this benefit if you want.
1 reply 0 retweets 0 likes -
Replying to @wycats @mweststrate and
2: you don't *also* have to enforce yet another copy of the name at the definition site.
1 reply 0 retweets 0 likes -
Replying to @wycats @mweststrate and
3: the way to think about it imo is that the name of the default export is the name of the module, so it was already named.
1 reply 0 retweets 0 likes -
Replying to @wycats @mweststrate and
4: import assign from "extend" can be seen as quite funny-looking (just like renames) and again can be linted.
1 reply 0 retweets 0 likes -
Replying to @wycats @mweststrate and
5: In practice, there are large codebases with one-class-per-module that benefit a lot from the simplicity of using the module as ...
1 reply 0 retweets 0 likes
6/6: the identity of the class rather than the module + a name (which ends up needing a convention anyway to avoid eye-stabbing)
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.