Hacker News Reader

Comment by sanitycheck | Hacker News Reader

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.

View on HN

Typescript 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.

Wouldn'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

A 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/no-for-in-array

https://typescript-eslint.io/rules/no-duplicate-type-constit...

Is there no incremental lint mode? When developing you need that for instant feedback, same mechanism should work for CI.

One 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.

Reply on news.ycombinator.com