ESLint and Prettier setup for Node.js means wiring a linter that finds problems to a formatter that fixes style, then stopping the two from arguing over the same lines. The 2020 approach used .eslintrc.json plus eslint-config-prettier. ESLint 9 in 2024 moved the default to flat config, so the exact steps below changed even though the goal did not.
ESLint and Prettier setup: what the two tools actually do
ESLint and Prettier setup works because the tools have separate jobs: ESLint is a static analyzer that flags unused variables and suspicious patterns, while Prettier is an opinionated formatter that rewrites whitespace, quotes and semicolons. Prettier has no view on whether your code is correct.
The 2020 video from the channel Gustavo Dev Doido, published on 30 May 2020 under a five-minute runtime, treats the pair as a style guide for a Node.js project started in earlier lessons. The host installs ESLint, adds Prettier as the formatter, then saves a file and watches the indentation change.
That split is still the design intent in 2026. Prettier's own documentation describes it as an opinionated code formatter that removes original styling and reprints code from scratch. ESLint's documentation frames rules as checks that catch likely bugs and enforce team conventions.
Keeping the boundary clean is what makes a style guide survive a team. A linter asked to format badly will keep producing disagreements that reviewers then settle by hand.
Why ESLint and Prettier conflict, and what eslint-config-prettier does
ESLint and Prettier conflict because some ESLint rules, such as indent, quotes and semi, encode formatting choices, and Prettier makes the same choices differently; eslint-config-prettier fixes this by turning those overlapping rules off.
The 2020 video installs three libraries for this reason: prettier, eslint-config-prettier and eslint-plugin-prettier. The shared config disables the formatting rules, and the plugin runs Prettier through ESLint as a lint rule so formatting shows up in the same report.
Current documentation for eslint-config-prettier describes it as a config that turns off all rules that are unnecessary or might conflict with Prettier. The plugin is optional, and many teams skip it so formatting stays a save-time action rather than a lint error.
The package is still maintained in 2026 and is published from the prettier organization on GitHub. Its install line in older tutorials, npm i eslint-config-prettier --save-dev, is unchanged; only the way the config is consumed has moved.
The original 2020 ESLint and Prettier steps, in order
The 2020 setup ran six steps: initialize ESLint, answer its questions, install Prettier and its helpers, then add the config entries the video demonstrated on camera.
- Open the command palette in VS Code with Ctrl+Shift+P and set editor.formatOnSave plus the default formatter so saved files are formatted automatically.
- Run
npx eslint --initand choose the options for syntax checks, problems and code style, JavaScript modules, browser environment, and a popular style guide. - Pick the style guide the host calls the popular one, which the transcript renders phonetically as if it were named after Anhembi; the init prompt in that era offered Airbnb, Standard and Google as the common choices.
- Delete the package-lock.json file if the project uses Yarn, because the wrong lockfile causes noisy diffs.
- Install prettier, eslint-config-prettier, eslint-plugin-prettier and a Babel parser package so ESLint understands newer JavaScript syntax.
- Extend the prettier config in the .eslintrc.json extends array, set the parser to the Babel option, and add
import/prefer-default-export: offto the rules block.
The video's error-prevention claim is modest: the Babel parser lets ESLint parse current JavaScript syntax instead of failing on it. It does not make the code correct.
That sequence worked in May 2020 because ESLint read .eslintrc.json by default and the project was plain JavaScript with no TypeScript step.
What changed by 2026: flat config replaced .eslintrc
By 2026 the file changed: ESLint 9, released on 5 April 2024, made flat config the default and moved .eslintrc support behind a compatibility flag, so a new project writes eslint.config.js instead of .eslintrc.json.
Prettier 3, released on 5 July 2023, made formatting asynchronous and dropped several legacy options. The config file names did not change, so .prettierrc and .prettierignore still work as before.
The packages the video installed still exist. eslint-config-prettier and eslint-plugin-prettier both publish current versions and document flat-config usage, so the dependency list carries over even though the extends array does not.
A current ESLint and Prettier config for Node.js
A current setup declares the two configs in eslint.config.js instead of an extends array, and keeps the same division of labor the video described.
| Layer | Package | Role in 2026 |
|---|---|---|
| Linter | eslint | Finds unused variables, undefined names, suspicious patterns |
| Formatter | prettier | Rewrites whitespace, quotes, line width |
| Rules off | eslint-config-prettier | Disables formatting rules that clash with Prettier |
| Format as lint | eslint-plugin-prettier | Reports Prettier differences as ESLint errors, optional |
| Parser | @babel/eslint-parser | Parses newer JavaScript syntax the default parser rejects |
A minimal flat config spreads the shared config after the base rules so it wins the overlap, then adds the team's own rule choices. The video's import/prefer-default-export: off entry belongs in that final object.
Save-time formatting still belongs in editor settings. The video used the command palette to set format-on-save and the default formatter; current VS Code exposes the same two settings, so that part of the instructions has not moved.
One practical difference: the async Prettier 3 formatter requires awaiting it inside the ESLint rule, and eslint-plugin-prettier's documentation covers that pattern. Copying a pre-2023 plugin configuration can leave formatting silently skipped.
Common mistakes in ESLint and Prettier setup
Most broken setups come from overlapping ownership: formatting rules left enabled in ESLint, configs listed in the wrong order, or a lockfile from the wrong package manager.
- Listing eslint-config-prettier before other configs, which lets a later config re-enable the formatting rules it just disabled.
- Running ESLint and Prettier as separate save actions without turning off the overlapping ESLint rules, so each tool undoes the other.
- Committing a package-lock.json from npm in a project that installs with Yarn, which the 2020 video avoids by deleting the stray lockfile.
- Assuming a shared config also fixes TypeScript or framework-specific rules; those need their own parser and plugin entries.
- Expecting Prettier to catch bugs. It only changes appearance, which is why both tools exist.
Each mistake has the same root cause: a rule set that still believes it owns formatting. The cleanest fix is to name one owner and disable the other side's formatting rules outright.
Who this setup still suits
The 2020 approach still suits small JavaScript projects, but teams on TypeScript or a framework will need extra configuration beyond what the video covers.
Crazystack is a Brazilian development training brand, and its courses cover TypeScript and Node.js tooling; readers coming from that kind of curriculum will hit the extra parser and plugin steps that the plain-JavaScript video skips. Crazystack TypeScript material in that curriculum addresses the typed variants directly.
The original video's audience was beginners learning Node.js on the channel of Gustavo Dev Doido, whose host performs in character as a fashion-advice persona named Arlindo. The instructions are deliberately shallow: enough to stop arguments about indentation, not a full quality pipeline.
For a project with TypeScript, JSX or framework-specific rules, expect to add a parser, a plugin and a type-aware config on top of this base. The shared prettier config still does its job there, which is why it remains a common first install.
FAQ
- Do I still need eslint-config-prettier in 2026? Yes, if ESLint still loads stylistic rules. The package turns off rules that conflict with Prettier, and current releases document flat-config usage, so it keeps working after the move from
.eslintrc.
Frequently asked questions
- Do I need eslint-plugin-prettier? No. Prettier can format on save without ESLint involvement, and adding the plugin makes formatting differences appear as lint errors, which some teams prefer and others reject.
- What is the minimum install for a JavaScript project? Install eslint, prettier and eslint-config-prettier as dev dependencies, create a flat config, and set format-on-save in the editor. That covers the job the 2020 video demonstrated.
- Why does ESLint still complain about indentation? A rule that controls indentation is still enabled, usually because the shared prettier config is listed before another config that re-enables it. Put eslint-config-prettier last so it wins the overlap.
- Does this setup cover TypeScript? No. TypeScript needs its own parser and plugin, and the plain-JavaScript config in the video will not check typed rules. Add the TypeScript tooling on top of the prettier config.
- Is Prettier 3 a breaking change for this workflow? It changed formatting behavior and made the API asynchronous. A plugin configuration written for Prettier 2 can silently skip formatting, so check the plugin docs for the current pattern.
- Can Prettier find bugs? No. Prettier only reprints code into a consistent shape. ESLint is the tool that flags unused variables, undefined names and suspicious patterns.
- Why did the 2020 tutorial delete package-lock.json? The project installed packages with Yarn, so an npm lockfile would be ignored or cause drift. Deleting it keeps one lockfile per project.
- Does format-on-save replace running ESLint in CI? No. Editor formatting fixes local style, while CI runs the linter and fails the build on rule violations, so the two serve different purposes.
- Where should the import/prefer-default-export rule go? In the final rules object after the shared config is spread into the flat config array, so your own choice overrides the default.
- Is the Anhembi style guide real? No package by that name appears in the ecosystem. The video is describing the style guide offered when running
npx eslint --initin 2020, most commonly Airbnb when the host says the name phonetically.
- Will this become outdated again? ESLint has changed its config format before and may again. Pin the versions in package.json so a future major release does not silently change parsing behavior.
- Does the setup work outside Node.js? Prettier handles many languages, while ESLint is built around JavaScript and TypeScript. Browser projects need environment settings, which the init prompt in the video selected.
Turning a tooling lesson into a written guide
The setup above is a tidy example of knowledge that only exists in someone's head and in a five-minute recording. The reasoning behind each step, the config order, the lockfile cleanup, is not on screen, and a viewer who hits a broken save loses the thread.
Writing it down forces that reasoning into the open, and it gives readers something they can search, compare across versions and adapt to their own project. A video made in 2020 and revisited in 2026 is exactly the case where a written version earns its place.
If you have explanations like this sitting inside YouTube videos, Skala blog takes a video URL, transcribes it and generates a draft article you can review and edit before publishing.