4 ms·

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

by johnfn 4y ago

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.

qudat 4y ago
This is the best I could find: https://stackoverflow.com/questions/44676944/how-to-compile-a-specific-file-with-tsc-using-the-paths-compiler-option/60950355#60950355 https://stackoverflow.com/questions/44676944/how-to-compile-...
wdfx 4y ago
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.
Normal_gaussian 4y ago
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.
- WorldMaker 4y ago
  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.
- johnfn 4y ago
  Wow, can't believe I never thought to try this before. That's a huge improvement, thanks!
adamddev1 4y ago
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 https://stackoverflow.com/a/60116499/8620945
deleted 4y ago
[deleted]
kitten_mittens_ 4y ago
https://www.typescriptlang.org/docs/handbook/project-references.html https://www.typescriptlang.org/docs/handbook/project-referen... might help out.

by johnfn 4y ago

qudat 4y ago

This is the best I could find: https://stackoverflow.com/questions/44676944/how-to-compile-a-specific-file-with-tsc-using-the-paths-compiler-option/60950355#60950355 https://stackoverflow.com/questions/44676944/how-to-compile-...

wdfx 4y ago

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.

Normal_gaussian 4y ago

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.

WorldMaker 4y ago
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.
johnfn 4y ago
Wow, can't believe I never thought to try this before. That's a huge improvement, thanks!

adamddev1 4y ago

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 https://stackoverflow.com/a/60116499/8620945

deleted 4y ago

[deleted]

kitten_mittens_ 4y ago

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