I’ve literally just put ts-ignore in many many files. The reason was legacy stuff, we had the ts check off (which blocks a merge if it failed), because there were just too many files that would need fixing. We thought about the best way to add the check so that new files have to have proper types, while having an easy way to slowly fix old ones.
We decided to go with ts-ignore for every file and a lint warning for the same line. So you see it in each file if it needs to be fixed, but you’re not going blind for red ts errors everywhere or don’t have the check at all.
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.
I disagree that you’re worse off (the core of my comment was that even a shitty migration encourages better practices)… but I wasn’t super familiar with TS hinting - using ts-ignore would be preferable.
Personally, I mostly work in PHP and we use a similar system. Strict typing is default off so we’ve slowly propagated declare(strict_types=1); to enable compile and runtime checking on a per file basis.
deleted by creator
Just as irritating as seeing people use linters only to have a lot of files with @ts-ignore all over the place… Like why even bother?
oh you’ve got a private variable that I want to use? No worries, (foo as any)[‘secret’].
I’ve literally just put ts-ignore in many many files. The reason was legacy stuff, we had the ts check off (which blocks a merge if it failed), because there were just too many files that would need fixing. We thought about the best way to add the check so that new files have to have proper types, while having an easy way to slowly fix old ones.
We decided to go with ts-ignore for every file and a lint warning for the same line. So you see it in each file if it needs to be fixed, but you’re not going blind for red ts errors everywhere or don’t have the check at all.
using
anyis 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… :/That’s the joke
I don’t follow, stamping every function with
: anylets 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.deleted by creator
I disagree that you’re worse off (the core of my comment was that even a shitty migration encourages better practices)… but I wasn’t super familiar with TS hinting - using ts-ignore would be preferable.
Personally, I mostly work in PHP and we use a similar system. Strict typing is default off so we’ve slowly propagated
declare(strict_types=1);to enable compile and runtime checking on a per file basis.tbh I don’t remember why I’m using TypeScript
deleted by creator