Two tools, two main jobs
ESLint analyzes JavaScript code against a set of rules. Some rules flag likely mistakes, such as a variable that is used but never defined. Others enforce conventions chosen by a project. ESLint reports where a rule was broken; it can also fix certain problems automatically when run with its fix option. Which issues it catches depends on the configuration and any plugins you install.
Prettier formats code. It makes choices about spacing, indentation, line wrapping, quotes, and similar presentation details so that files have a consistent appearance. Rather than offering many individual style rules, it applies its formatting decisions to the file. Prettier is not a substitute for a linter: neatly formatted code can still contain unused variables or other mistakes.
What a beginner might notice in practice
Imagine you write a JavaScript function and misspell the name of a variable when you use it. With an appropriate ESLint configuration, a rule such as no-undef can flag the unknown name. Prettier may adjust the function’s layout, but it will not identify the misspelling as an error. Conversely, if a line has uneven spacing or an awkward break, Prettier can make its appearance consistent even when ESLint has no complaint.
Neither tool proves that a program behaves as intended. ESLint can catch patterns covered by its rules, but it cannot know every requirement of your project. Prettier checks formatting, not correctness. You still need to run the program and write tests for behavior that matters. Think of the tools as a way to shorten the feedback loop, not as a replacement for debugging.
When to use one tool or both
Use Prettier when consistent formatting is the immediate goal, especially if you want to spend less time discussing where lines should break or how code should be indented. Use ESLint when you want automated feedback about suspicious code and project-specific coding rules. For most JavaScript projects, using both is reasonable: Prettier handles appearance, while ESLint handles code rules.
The overlap needs a little care. ESLint can be configured with stylistic rules that disagree with Prettier’s output. If formatting a file causes lint errors, do not keep alternating between the two tools to satisfy conflicting settings. Remove the overlapping style rules or use eslint-config-prettier, a configuration package designed to turn off conflicting ESLint formatting rules. It does not replace either ESLint or Prettier.
A small JavaScript setup
For this example, use npm, a Node.js version supported by the packages you install, ESLint 9, and Prettier 3. Check the packages’ Node.js requirements before installing them. From your project folder, run npm install --save-dev eslint@9 @eslint/js@9 prettier@3. This installs the tools locally so the project can record them as development dependencies.
ESLint 9 needs a configuration file before a typical lint run. For a small JavaScript project, create a file named eslint.config.mjs containing two lines: import js from "@eslint/js"; and export default [js.configs.recommended];. This enables ESLint’s recommended JavaScript rules. If your code relies on browser globals such as document, you will need to configure those globals separately; otherwise, ESLint may report them as undefined. Add other rules only when you have a reason to use them.
Run npx eslint . to lint the project. Run npx prettier . --check to see whether supported files match Prettier’s formatting, without changing them. When you are ready to format files, run npx prettier . --write. Review the resulting changes, particularly the first time you run it on an existing project. These commands assume you run them from the project folder; you can name specific files instead of using the dot when you want a narrower check.
Make the workflow easy to repeat
A practical routine is to format while you work, then run the lint and format checks before sharing a change. Many editors can run Prettier on save and display ESLint warnings as you type. Editor integration is convenient, but keep the command-line checks available so you can repeat them without depending on one person’s editor settings.
Start with a small rule set and clear ownership: Prettier decides formatting; ESLint flags the code patterns your project cares about. If a warning is confusing, read the rule description and inspect the surrounding code rather than suppressing it immediately. That habit helps both tools serve their real purpose: making code easier to maintain while leaving decisions about program behavior to you and your tests.
