And has some really odd behaviors like https://github.com/microsoft/TypeScript/issues/17053

Are you saying typescript should parse regular expressions?

Turn on `noUncheckedIndexAccess` and it works as you expect (plus forces you to check all the places you're doing unchecked access).

https://www.typescriptlang.org/play/?noUncheckedIndexedAcces...

Regular expressions are part of the language, so it's not so unreasonable that TypeScript should parse them and take their semantics into account. Indeed, TypeScript 5.5 will include new support for syntax checking of regular expressions[1], and presumably they'll eventually be able to solve the problem the GP highlighted on top of those foundations.

[1]: https://github.com/microsoft/TypeScript/pull/55600

That's crazy, in the best way

Yet it's the best we have at the moment in terms of statically typed JS (other than JSDoc which encodes the type system in comments, which .. has its own issues).

Does JSDoc even have a type checking system? The point of TS is that is actually does something with your declared types. JSDoc is nice... for docs being interpreted by a human. But unless those are used to create red squigglies then it's kind of arbitrary.

I've used JSDoc with TS's type syntax and typechecker in JS files. Which is fine - I find it subjectively uglier but I know some prefer it. But it's still TS that's doing the actual work of determining if all my annotations are compatible when the rubber hits the road.

JSDoc provides the exact same level of type safety as TypeScript, because the TypeScript Language Server/CLI themselves are what does the type checking. Using JSDoc removes the need to transpile your code before executing it. You still want to type-check your code (with a `tsc --noEmit` or similar) in CI, just like you'd run unit tests/a linter/etc.

Yes, that's my point. JSDoc isn't an alternative to TypeScript if you want your types to actually be checked.