It’s a good way to get started, and then incrementally type as much as you can, preferably everything.
Later on, or if you start a new project with TypeScript, it’s a good idea to turn on
noImplicitAny
and only allow explicitany
in very specific framework level code, unit tests or if you interface with an untyped framework.The hassle really pays off later.
this is terrible advise - you should be using
unknown
. usingany
you’re basically disabling TS and will be under the false assumption that your code is ok while it’s most likely missing a lot of runtime checksBut if your code ever integrates with javascript you still need any everywhere so it’s pretty pointless
Not true, in the absolute worst case,
unknown
is what you should be reaching for, but it’s pretty rare that you can’t create some kind of type to interface with JS if it’s not already got types. You can even use jsdoc comments as type hints in the JS too if you own that code.My not particularly hot hot-take: There’s basically no legitimate use case for
any
apart from “I don’t have time to type all this now, because I’m converting a massive project from JS to TS”There are some cases where
any
must be used instead ofunknown
but they usually involve generic constraints and seem more like a bug than intended behaviorAh you’re right there, and I also agree, that feels more like a bug than by design
Not necessarily, depending on your situation you can type the JS code yourself.
If the team making the JS code were using jsdoc then the Typescript compiler can recognize the comments and use it for type checking.
In some instances the compiler can infer types from JS code to do some basic validation.
Even if the external JS code is recognized as
any
, your own code that’s using it still has types, so it’s better than nothing.
I knew my any key would be useful one day.
an any
But it’s “a colon any” 🧐
Typing < type hinting
Why not use assembly ?
Nah this isn’t the way, friend. Instead of adding a bunch of useless anys all over the place, start typing in one part of the application and exclude the rest using a path pattern. Or simply allow .js and only change the extension for files you’ve typed. Doing this is just wasting time and creating false assurances of type safety.
It’s not that hard to define correct, meaningful types. Often vscode already has implicitly determined them for you; just mouseover the variable.I wish I did that, at this point my TypeScript template errors are as long as C++'s ._.
deleted by creator
Ah yes, node, the JS runtime that very famously doesn’t ever get used with typescript
Managing a node project is like juggling twelve barrels full of monkeys… and those monkeys have rabies. Trying to keep all your dependencies in line is insane.
Just use npm to install all the dependencies. What’s the worst that can happen.
It is absolutely insane to me that people rag on the Python packing ecosystem when TypeScript exists. Sure, Python’s not perfect (Rust and Go seem better, from the small amount I’ve dabbled with them), but way easier and more stable than any TS project I’ve worked on.