Glossary / Linters
Linters
A linter analyzes source code for patterns that may be incorrect, unsafe, inconsistent, or contrary to project conventions. In JavaScript and TypeScript, linters such as ESLint operate on parsed syntax and rules; they complement type checking, formatting, tests, and code review rather than replacing them.
Rules and configuration
A rule can report syntax patterns, enforce restrictions, or provide an automated fix when semantics are safe. Plugins add domain-specific rules; shareable configs bundle policy. Flat config is the current ESLint configuration model, while older .eslintrc files use the legacy system; migration and plugin compatibility depend on versions. Type-aware rules may invoke TypeScript program analysis and cost more than syntax-only linting.
Lint rules can catch undefined names, unsafe patterns, accessibility issues, import boundaries, and framework mistakes. They cannot prove runtime behavior or system correctness. Auto-fixes can change code and should be reviewed, especially for rules that reorder imports or rewrite logic. Conflicting rules across editor, CI, and repository scripts create noise and erode trust.
Engineering guidance
Use a focused baseline with high signal, run it consistently in CI and editor, and establish a process to suppress rules with explanation and scope. Separate formatting from semantic linting where appropriate. Pin config/plugin versions, track lint duration, and make autofix policy explicit. Gradually adopt stricter rules instead of turning on a large noisy policy all at once.
Interview questions
- Linter vs type checker? Linters inspect code patterns and policy; type checkers analyze type relationships.
- Can lint prove code correct? No; it catches selected classes of issues.
- Why can type-aware linting be slower? It needs project-wide type information.
- How handle false positives? Narrow, documented suppressions and rule/config refinement.
- Should fixes be automatic? Safe mechanical fixes can be; review semantic or broad changes.