Biggest pet peeve is how VSCode doesn’t seem to surface errors across the whole project: I have to open up files that were affected by a rename of an exported symbol to see red squigglies show up. Feels regressive from a usability perspective, as the computer knows this information, and all the older languages of yore could do this easily in an IDE.
I’m able to do that in IntelliJ. I was surprised it didn’t come up as a setting in vscode. It looks like they’ve been trying to solve the issue since 2016.
I always find it interesting to see how people respond to the “type checking as a separate step” aspect of Typescript. I think it breaks a lot of people’s brains — it feels unsafe, because you’re able to run code that you’ve never type checked. How can this be?
I’ve grown to really appreciate the type checker working in this way, though. It gives very much a “best of both worlds” feeling. I can do the follow-the-red-squigglies style of refactoring, because my editor shows all the errors in a file, and I usually have tsc running in watch mode in a terminal as well. However, there are some times when I might break the types deliberately to test something out. For example, I might have an event handler that handles a bunch of different tests, but I’m only interested in debugging the click event right now. I can add some logs that’ll only work for click events, and Typescript will complain at me because I’m not handling the other cases properly. But as long as I only send the click event while debugging, then I’m not going to run into any errors. And the squigglies are there to remind me to delete that code as soon as I’m finished working — it’s never going to get checked in, and even if it did, the build would fail and that code will never get released.
The result is that it behaves a lot more like linting than a compiler, but linting with far fewer false positives or false negatives because you’ve annotated all the code so the linter can analyse it better. You’ll always run the linter before committing and pushing code, and if you delete some code, you can follow the trail of linter warnings about unused code to delete anything else that isn’t needed any more. But at the same time, you don’t need to delete that unused code to get the program to run while you’re developing, which means you can try things out much more easily than if you were forced by the compiler to have perfect code every time the program runs.
If it behaves like a linter, then it has the same failure modes as a linter, right? It’s fine if you’re working by yourself and have a process to check for type errors, but in the context of an engineering team, I can almost guarantee people will manage to commit broken code.
On the one hand it allows running unchecked code, on the other hand I’ve seen PRs which had never been run at all. So even with a compiled langage with a strong type system and mandatory type checking you must have a CI as soon as someone else is involved.
It’s true that it’s not 100% perfect, but it’s not really difficult to just wire it up to CI.
Notably, in terms of actually building some sort of release version, people will actually often rely on tsc to do the transpiring, in order to avoid needing TS in e.g. your docker containers. That does also mean that you generally can’t do the release build w/ type errors, even if you could run your dev server with them.
Typically that would be stopped via CI. I typically work with feature branches, so a branch cannot get merged with passing type checking (and linting, tests etc). You could also use pre-commit or pre-push hooks to ensure that no bad code even gets committed.
And as the sibling comment points out, you would never do a build without running the type checker. Even if I weren’t using tsc as the compiler directly, I’d still always run the type checker (plus lints, tests, etc) before any build. So even if your git process is fairly sloppy, you can always see what’s building and what isn’t, and fix that quickly.
I’m starting to find a groove with TS.
Biggest pet peeve is how VSCode doesn’t seem to surface errors across the whole project: I have to open up files that were affected by a rename of an exported symbol to see red squigglies show up. Feels regressive from a usability perspective, as the computer knows this information, and all the older languages of yore could do this easily in an IDE.
I’m able to do that in IntelliJ. I was surprised it didn’t come up as a setting in vscode. It looks like they’ve been trying to solve the issue since 2016.
https://github.com/microsoft/vscode/issues/13953
I always find it interesting to see how people respond to the “type checking as a separate step” aspect of Typescript. I think it breaks a lot of people’s brains — it feels unsafe, because you’re able to run code that you’ve never type checked. How can this be?
I’ve grown to really appreciate the type checker working in this way, though. It gives very much a “best of both worlds” feeling. I can do the follow-the-red-squigglies style of refactoring, because my editor shows all the errors in a file, and I usually have
tscrunning in watch mode in a terminal as well. However, there are some times when I might break the types deliberately to test something out. For example, I might have an event handler that handles a bunch of different tests, but I’m only interested in debugging theclickevent right now. I can add some logs that’ll only work for click events, and Typescript will complain at me because I’m not handling the other cases properly. But as long as I only send the click event while debugging, then I’m not going to run into any errors. And the squigglies are there to remind me to delete that code as soon as I’m finished working — it’s never going to get checked in, and even if it did, the build would fail and that code will never get released.The result is that it behaves a lot more like linting than a compiler, but linting with far fewer false positives or false negatives because you’ve annotated all the code so the linter can analyse it better. You’ll always run the linter before committing and pushing code, and if you delete some code, you can follow the trail of linter warnings about unused code to delete anything else that isn’t needed any more. But at the same time, you don’t need to delete that unused code to get the program to run while you’re developing, which means you can try things out much more easily than if you were forced by the compiler to have perfect code every time the program runs.
If it behaves like a linter, then it has the same failure modes as a linter, right? It’s fine if you’re working by yourself and have a process to check for type errors, but in the context of an engineering team, I can almost guarantee people will manage to commit broken code.
On the one hand it allows running unchecked code, on the other hand I’ve seen PRs which had never been run at all. So even with a compiled langage with a strong type system and mandatory type checking you must have a CI as soon as someone else is involved.
It’s true that it’s not 100% perfect, but it’s not really difficult to just wire it up to CI.
Notably, in terms of actually building some sort of release version, people will actually often rely on tsc to do the transpiring, in order to avoid needing TS in e.g. your docker containers. That does also mean that you generally can’t do the release build w/ type errors, even if you could run your dev server with them.
Typically that would be stopped via CI. I typically work with feature branches, so a branch cannot get merged with passing type checking (and linting, tests etc). You could also use pre-commit or pre-push hooks to ensure that no bad code even gets committed.
And as the sibling comment points out, you would never do a build without running the type checker. Even if I weren’t using
tscas the compiler directly, I’d still always run the type checker (plus lints, tests, etc) before any build. So even if your git process is fairly sloppy, you can always see what’s building and what isn’t, and fix that quickly.Literally no reasonable way to run Typescript in this day and age.
Honestly, Typescript is the svn to Javascript’s cvs.
Deno works great for me!