jonturner, it’s interesting and a little scary that identifiers can be duplicated like that and it works. Is it planned that this will continue to work long-term? Are there defined rules about what overrides what in the specification when this is done?
It turns out there is more than one error code related to this condition; TS2027 is basically the same thing. I thought it was odd that this would have been the first time someone ran into this, but for some reason I was unable to find the other one when searching
the other day. So, there is a related discussion to this at
, for reference, that may contain additional rationale for not throwing these errors.
The workaround is OK, but it feels hacky, and I still am not entirely clear on what the rationale is for restricting named interfaces like this, and I would like to understand this.
Is the idea to intentionally roadblock people into doing things the Right Way? If so, it’s arguably a fair thing to do, but it makes prototyping components in TS annoying. (Yes, I will split out the interface later to one of our interfaces files, but I don’t
want to break my code flow right now
by having to go and do that.)
Is it an artefact of the lack of
until later versions of TS (so exporting the interface wasn’t a big deal before because you always had the ability to export multiple things)? If so, it should probably be re-evaluated.
Is there another reason? If so, I’d like to understand it.
Other than the above case, I have also experienced a need to create separate types when modelling inheritance that TypeScript can’t do correctly by itself (like extending Error, or multiple inheritance). In these cases, the type may be only used once ever (as
to manage mentally right now. This might be another topic for another thread.) I’d like to say these are weird edge cases but I seem to keep running into them. It feels like preventing use of private interfaces prevents me from having tidier code.
Thanks everyone for your input,