A tiny linter: rules, positions and a report
Positions are line:column, both counted from 1, like ESLint's report. Real ESLint doesn't search text: it parses the code into a tree first, so "var " inside a string or a comment never triggers no-var.
A linter such as ESLint reads your code without running it and reports likely bugs and banned patterns; a formatter such as Prettier rewrites the layout (spaces, quotes, line breaks) into one consistent style; your editor and a pre-commit check run both automatically.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write an eslint.config.js for a browser project that uses the recommended rules, makes eqeqeq an error and no-console a warning, and ignores the dist folder.
Write a function findLooseEquals(lines) that returns the 1-based line numbers containing == or != but not === or !==. Test it on ["a === b", "a == b", "a != b"].
Explain it without notes
What is the difference between a linter and a formatter? Name the usual tool for each.
Give three bugs ESLint catches that don't cause an error when the code runs.
How do you stop ESLint and Prettier from disagreeing?
Where should linting and formatting run in a team, and why in more than one place?
Preview
Console
Nothing logged yet.Expected console output
2:3 error Unexpected var, use let or const instead no-var
4:18 error Expected '===' and instead saw '==' eqeqeq
6:5 error Unexpected 'debugger' statement no-debugger
3 problems