3 ms·

I love strong types, but I disagree with the final note here: > The `any` type was a mistake and never should have been included in TypeScript in the first pla

I love strong types, but I disagree with the final note here: > The `any` type was a mistake and never should have been included in TypeScript in the first place. It is disappointing to see the number of published libraries that embrace `any` types, making it difficult to verify with certainty that code is correct. `any` is a consequence of TypeScript being JavaScript under the hood. Is `unknown` a better type to use when you're not sure what something might be? Sure, the fact that TypeScript forces you to carefully pick apart what it actually is by guiding you through the appropriate type narrowing is great. But sometimes you actually just want to write some code and sort out the types later, especially when you have a lot of interfaces that came from JS or from an only partially converted TS codebase that would otherwise be full of `as unknown as T`. I think the only mistake here was allowing the `noImplicitAny` tsconfig option to be off by default. When TypeScript can't figure out what a type is and that setting is off, it just decides that the type is `any`. But when that setting is on, it's an error to not explicitly state the type, even if you explicitly state it's `any`! Then any usage of `any` is explicit, auditable, lintable, etc. and then it's much less of a problem to use effectively.

ravenstine 3y ago
If all code was Typescript, maybe the author would have a sound point. Because of JavaScript (godblessit), there are many things that were written in a way that makes types difficult to implement. I work on Ember codebases and, while some of my colleagues who happen to work on Ember probably would disagree, there are things about the way it lazily resolves things makes it extremely difficult for everything to be typed properly without lots of recasting and bureaucracy that wouldn't have happened had the whole thing been written in Typescript from the very beginning. Typescript in Ember will always be a shitshow because of this design flaw that was encouraged by the era of JavaScript it was spawned from. Nevertheless, we shouldn't replace things that are otherwise working just fine, hence it's better to just accept that some things are going to be "any" or "unknown" and deal with them properly.

ravenstine 3y ago

If all code was Typescript, maybe the author would have a sound point. Because of JavaScript (godblessit), there are many things that were written in a way that makes types difficult to implement. I work on Ember codebases and, while some of my colleagues who happen to work on Ember probably would disagree, there are things about the way it lazily resolves things makes it extremely difficult for everything to be typed properly without lots of recasting and bureaucracy that wouldn't have happened had the whole thing been written in Typescript from the very beginning. Typescript in Ember will always be a shitshow because of this design flaw that was encouraged by the era of JavaScript it was spawned from. Nevertheless, we shouldn't replace things that are otherwise working just fine, hence it's better to just accept that some things are going to be "any" or "unknown" and deal with them properly.