> For example, the no-floating-promise[0] rule catches some easily-made mistakes involving promises in a way that TypeScript doesn't on its own.
Is there a fast linter that checks for this? I find this error easy to make as well, and it usually causes weird runtime behaviour that's hard to track down.
Even if it’s not official i could use a slimmed-down, faster TypeScript. Even if it has slightly different semantics. I always use skipLibCheck so TS only checks my code.
It’s a form of linting, not semantics, so it doesn’t have to be exact.
Similarly, tslint operates best as a Typescript plugin and so lint rules in Typescript still can happen at transpile time and aren't necessarily that much different in practice from compiler errors. Still bugs me a little that there's not a higher-kinded type or pattern that I can come up with to do it "for real" in the compilation.
With C++ the usual solution is to use only a defined subset of it and make sure that lint checker is used in presubmit checks. Exceptions to other types should be allowed, but strongly discouraged when working in a team (which TypeScript is used for)
I don’t think anyone mentioned typescript, which is statically typed and therefore can provide a noImplicitThis check in its linter. AFAIK eslint doesn’t provide that option.
That’s a JS WAT, and it’s fair to say TS should error, but TS is explicitly not a linter and the code is “correct” so it’s unclear what else it should do.
Some of those issues can be remedied by linting rules (preventing unsafe use of any), but typing of dependencies can be a headache. Even 1st party typing and Typescript dependencies can regularly be wrong if type safety was not important to whoever wrote them.
TypeScript code can be transpiled and executed even if there are type errors (just like how a linter doesn't stop you from running your code), so in that sense, it's also valid TypeScript.
I have a feeling you're talking about an old version of typescript. Versions 2.2+ (currently 2.3.2) are sound (but not fully so, just like flow) with the right flag(s).
Here's the description of the "strict" compiler option that goes a long way to make your program more reliable :
"Enable all strict type checking options.
Enabling --strict enables --noImplicitAny, --noImplicitThis, --alwaysStrict and --strictNullChecks."
This seems like a moving target though, and I still don’t think the typescript compiler should be responsible for it. I think a linter could make sense though for obviously bad cases.
TypeScript is a superset of JavaScript, so they can't just like.. stop you from writing valid JS. Generally speaking, any valid JS is valid TypeScript. It's not invalid to write that, so TS won't do anything to stop you from doing so. However, fortunately linters exist for the exact reason of catching these sort of "gotchas" or "probably not what you were intending" kind of situations.
Cool! Does it enforce third-party libraries as well?
A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? This can cause sneaky bugs later :/
I'm not saying that typescript/flow is bad. Whenever I have to use node.js, I end up using typescript. But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be.
this is why I wish typescript added runtime checks in development. Worst case, it would throw a TS error in your browser any time a function call or a network request didn’t match what you typed
Afaik, typescript is pretty bad in terms of catching some basic errors. Types are not enforced. A caller can change sync function to async, breaking the functionality downstream.
Yes, I'm stoked you brought this up, as I had previously googled and found some articles that recommend doing this in typescript. I haven't tried it out yet though, mainly because it seems like every article has a different approach to production-ready error handling in typescript and I don't know the best approach. Do you / does anyone have any suggestions for articles etc. on this?
reply