4 ms·
I think if my CI was taking 45 mins to lint I'd look at linting only the files changed since the previous build instead of splitting it across 40+ workers. Or w
by sanitycheck 3y ago
I think if my CI was taking 45 mins to lint I'd look at linting only the files changed since the previous build instead of splitting it across 40+ workers. Or writing a new linter in Rust.
But I'm generally working in a (human & financially) resource-constrained environment.
- throwup238 3y agoTypescript lints are type-aware so you can’t just lint changed files, you have to relint the entire codebase to check if any type changes have impacted the unchanged code.
- pcthrowaway 3y agoWouldn't an issue with a type change be caught at typescript compile/check steps? I'm not aware of eslint rules which would complain about some other untouched file if types have changed in ways such that the program still compiles
- anamexis 3y agoA few examples of typescript-eslint rules that could fail when a type in another file is changed: https://typescript-eslint.io/rules/await-thenable/ https://typescript-eslint.io/rules/await-thenable/ https://typescript-eslint.io/rules/no-for-in-array https://typescript-eslint.io/rules/no-for-in-array https://typescript-eslint.io/rules/no-duplicate-type-constituents https://typescript-eslint.io/rules/no-duplicate-type-constit...
- Too 3y agoIs there no incremental lint mode? When developing you need that for instant feedback, same mechanism should work for CI.
- arp242 3y agoOne problem is that a change in a.js may trigger a new error in b.js. ESLint could also cache things fairly trivially: hash = hash_file_contents() if previously_seen_hashes.contains(hash) report_previous_results() else run_lint_and_cache_results() end maybe that already exists. But that has the same problem. When you've got enough hardware to throw at it, then "just run it on the full code" is the safest.