Hacker News new | ask | show | jobs
by aconbere 1677 days ago
I have to admit i’m baffled by this suggestion. I get that compilation and type checking offer different value propositions, but i’ve now walked into a couple of projects that were happily compiling their typescript with babble only to realize once compiling with tsc that there were rampant type errors.

I find this idea of throwing away safety for compilation speed to be a non-option.

3 comments

It’s a perfectly fine option because it’s happening at developer time when you don’t care if it’s wrong. You’re IDE is likely providing typing insights anyway so waiting for the totality of the compilation to see the result of reloading your app isn’t necessary. It’s like using a potentially wrong cache that’s alerts your after the fact that the answer was invalid. Rather than waiting, you proceed to examine the results and likely refine your work before the relatively slow type checker validates the universe.

Now if you end up pushing code that hasn’t been type checked then that’s a different story. Might as well run “git yolo” if you’re not going to run type checks, linting or any other sanity tests before indicating you’re own personal sign off of a commit.

This just seems like a really long turn around time for type errors. This pushes global type checking into the space of unit testing in terms of time cost. I'd personally much rather have tsc take a second or two and give me the full picture than just hide my eyes until I run unit tests.
Could you elaborate?

Shouldn't the type checks happen while you write the code?

vscode + typescript seems to only surface errors in the current file. If a change breaks something in another file it isn't apparent (in my experience at least). I added tsc to a pre-commit hook to catch these issues.
Interesting.

I had the impression it would also include imported files.

Thanks! :)

Your CICD should validate types and lint and fifty other things. The developer when running a local compile does not need to but should before pushing.
Think about the various tools we have available to us in concentric rings, each with an increasingly longer period.

In the inner most ring, the most readily available, happening almost instantly, we have tools like syntax checking, maybe even LSP calls, linting. Time since writing the code is on the order of ms to a second.

In the outermost ring, the least available we have CICD, these checks happen rarely, often on a push to a central server. Time since writing the code is on the order of 10s of minutes to potentially hours.

I have a really hard time believing that folks are getting so little value out of types, have so few project wide issues, or are so willing to rewrite portions of their work to push type checks into the outer ring of CICD.

That's not what's happening. They're not pushing type checking to the outer ring. They are pushing cli driven gold standard type checking to an intermediate ring and worst case the outer ring. Their IDE can do 95+% of the type checking anyway and only when it fails do they need to escalate. However that escalation is rare and does not need to be done every single time they wish to compile something for local testing.