Linting vs. type checking vs. testing
Lint finds suspicious code, type checking rejects impossible value combinations, and tests run examples to check behavior.
What it is
Linting, type checking, and testing answer different questions. A linter such as Oxlint spots suspicious code patterns and enforces code rules; the name goes back to Stephen Johnson's 1978 Unix tool at Bell Labs, named for the fluff a dryer screen catches. A type checker such as TypeScript checks whether values and operations agree with declared types. A test runner such as Vitest executes chosen behavior with examples and checks the results.
Run all three because their blind spots overlap usefully. Lint can catch an unhandled promise, types can reject passing a string where a number is required, and a test can prove that the correctly typed pricing function still calculates the wrong total.
Gotcha: the boundaries are not perfectly clean. Linters can use type information, type systems can encode business rules, and tests can assert source structure. That overlap does not make the layers interchangeable. Three green checks mean only that each checked the claims it was given.
Ask AI for it
Create three independent GitHub Actions jobs for this TypeScript repo: lint with `bun x ultracite check`, type check with `tsc --noEmit`, and test with `vitest run --coverage`. Make all three required status checks, cache dependencies without sharing generated outputs between jobs, and give each job a distinct name and failure message. Add one deliberate example that only lint catches, one only TypeScript catches, and one only Vitest catches, then remove the examples after documenting the difference in CONTRIBUTING.md.