using any is actually much worse than using TS, because you're basically telling the compiler "don't help me here".. at least with JS the IDE is gonna help you.. :/
I don't follow, stamping every function with : any lets you merge the branch and deploy it... trying to properly type everything extends the initial migration time likely to a level where management just says no.
Use a combination of allowJs and ts-ignore, do progressive enhancement, and convert your codebase file by file. Adding any everywhere literally turns off type checking altogether codebase wide, including type inference. It also means a huge PR that's both just noise that needs to be fixed later, and messes with your git history (good luck getting anything useful out of blame or bisect now).
Just getting a green build doesn't mean things are okay. You're worse off than before doing that.
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 explicit any in very specific framework level code, unit tests or if you interface with an untyped framework.
this is terrible advise - you should be using unknown. using any 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 checks
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"
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.
Typescript is a language, Node is a platform and framework. You can use Typescript in your Node project, they're not mutually exclusive.
The way I see it Typescript is more popular than ever, almost all (popular) libraries come with types and every job offer I get they use Typescript.
And with good reason, our team recently took over a small Javascript app and there are tons of bugs that would never have existed if they were using Typescript. Things like they refactored something but missed to update a reference, or misspelled a variable name, failed to provide a required parameter to a funcrion, referenced a field that existed in another config object etc.
It’s about time JS gave us the ability to be strict on types, and have that as part of the interpreter as opposed to needing to transpile TS with the overhead involved
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.
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.