What is a linter? (the spell-checker for code)

What it actually is

A linter is a tool that reads your code without running it and flags patterns that are probably mistakes: a variable you declared but never used, a missing semicolon your language actually cares about, a comparison like == where you almost certainly meant ===. Think of it as a spell-checker for code. A spell-checker doesn’t know what your document is about, it just knows “flagrant” isn’t spelled “flagrent.” A linter doesn’t run your app either, it just knows that a certain shape of code tends to cause bugs, so it flags it before you find out the hard way.

The two names you’ll see most in a JavaScript or TypeScript project are ESLint (the linter) and Prettier (a formatter, not a linter, though people use the words interchangeably). ESLint checks for actual problems: an unused import, a variable that shadows one from an outer scope, an unreachable line of code. Prettier only rewrites how the code looks: line breaks, quote style, indentation. They solve different problems and most projects run both, one right after the other.

Why your AI just did this

When your agent runs eslint or npx prettier --write after editing a file, it’s catching two different kinds of risk. The linter catches things that will misbehave: an unused variable is often a sign that a piece of logic was half-finished, a missing dependency in a React hook can mean your UI silently goes stale. The formatter handles something else, keeping every file in the project looking like it was written by one person, which matters a lot when you (or a future agent session) come back to read it later.

Some projects also run linting automatically as a gate: a pre-commit check, or a CI step that blocks a deploy if npm run lint fails. If your agent says something like “fixing the lint errors before I continue,” it’s usually because one of those gates would otherwise reject the change outright.

When you’ll run into it

• Red or yellow squiggly underlines in your editor, VS Code shows these live as you type
• A terminal summary like 5 problems (3 errors, 2 warnings) after running npm run lint
• A specific message like 'data' is defined but never used no-unused-vars or Parsing error: Unexpected token
• Your agent pausing mid-task to say it’s cleaning up lint errors before moving on
• A deploy failing in CI with a lint step in red, even though the app works fine on your machine

What to check

• Run npm run lint yourself to see the full list, not just what your editor happens to show
• Errors block a deploy in most setups, warnings usually don’t, know which one you’re looking at
• A config file exists at the project root, usually eslint.config.js in current projects (older ones may still have a legacy .eslintrc.json), that’s what defines the rules
• If your agent adds // eslint-disable-next-line to silence a warning, ask why, that’s suppressing the message, not fixing the problem
• ESLint and Prettier aren’t fighting each other, some setups need eslint-config-prettier so their rules don’t contradict

Say it like a dev

Instead of: “the editor has red lines everywhere” Say: “the linter is flagging a few things, let’s see what npm run lint says”

Instead of: “make the code look nice” Say: “run Prettier to format it, that’s separate from fixing the lint errors”

Instead of: “just make the warning go away” Say: “is this safe to disable, or does it point to a real bug?”