3 ms·
Sure, I agree in general, but I've found that: 1. If someone is willing to do `as unknown as T`, they're probably also just as willing to do `// @ts-ignore`. 2
by leononame 2y ago
Sure, I agree in general, but I've found that:
1. If someone is willing to do `as unknown as T`, they're probably also just as willing to do `// @ts-ignore`.
2. It's not only your own code, it's the libraries you use as well. Typings can often be slightly incorrect and you have to work around that occasionally.
- mynameisvlad 2y agoFor #1, this is literally what PRs are for. Someone might be willing to do it, but it should be stopped before merge. If it isn’t, you have bigger problems to solve than type coercion. For #2, if it’s open source you’re welcome to change the source or its typings.
- cdaringe 2y agoPopular libraries tend to get type hygiene issues ironed out rather quickly for 90% of the API surface area. For this reason, i find that lib selection from npm is much easier these days. The heuristic is simple: 1) has types? 2) has (large) download count? 3) has docs? After that it’s generally smooth sailing. Of course this doesnt at all apply to the application codebase being applied to, but one of the parent/sibling remarks emphasized “madness” and i seek to smooth that over. Noisy? Yes. Madness? Nah.
- tuwtuwtuwtuw 2y agoDon't you care about whether it's an abandoned project, how many dependencies it has or its license? Your simple heuristics seems like a bad approach to me.
- nox101 2y agoYou can also turn off all warnings in C and C++ (and C#?). That's not a flaw in the language it's a flaw in code bases and programmers that turn them off.
- tshaddox 2y agoThen fail builds on @ts-ignore. "But the bad dev will just open up your build config and remove that restriction." Okay fine. At some point you gotta establish a floor on the insolence of your teammates.