Hacker News Reader

Comment by johnfn | Hacker News Reader

This seems on topic and it's something I've wondered for a while. Does anyone have any good strategies for quickly running TypeScript against an entire repo?

I want to be able to quickly validate that a change that I made didn't introduce any errors. The problem is that our repo is a few hundred thousand lines, and doing `yarn run tsc` takes a long time. I currently use VSCode, which does good at incremental feedback in the current file, but there's still a blind spot where I'm not sure if I've introduced issues that affect files that I'm not currently editing.

View on HN

To see errors appear on all files in a project you can turn on this experimental feature:

"typescript.tsserver.experimental.enableProjectDiagnostics": true

This has been a game-changer for me. Any files in the project that are broken immediately show up as red and then I can go find what's wrong. It's a refactoring dream. I use an M1 Mac and it does just fine with big projects.

Source: https://stackoverflow.com/a/60116499/8620945

Typescript in watch mode in a background process (with compilation output on or off) is the default recommendation here. (and what I do, alongside prettier formats and some macros).

That is effectively what happens in VSCode, via the lsp, so I'm guessing something is being lazy and its a bug with the integration.

My understanding is that VSCode's use of the LSP does a lot of "horizon shortening" to keep things performant in a large workspace. If the workspace is small enough it does seem to check every file all the time, as the workspace grows it starts to prioritize open editors and gets lazier about checking other files, and I've even seen situations where it prioritizes the current editors (visible tabs/splits) entirely over even the rest of open editors. I don't think it's necessarily "a bug", but it's certainly seems an intentional laziness to prioritize the editing experience over the compile experience.

Which is a long winded thing to say that it's still often useful in VS Code to keep a full tsc --watch process around even if you think the LSP's horizon is wide enough to catch everything because tsc --watch will always have different performance priorities to VSCode's editing experience.

Wow, can't believe I never thought to try this before. That's a huge improvement, thanks!

This is the best I could find: https://stackoverflow.com/questions/44676944/how-to-compile-...

Break your package up into multiple smaller packages in a monorepo. Use tsc incremental and something like nx which can cache and only rebuild changed packages.

https://www.typescriptlang.org/docs/handbook/project-referen... might help out.

Reply on news.ycombinator.com