VS Code for teams: formatting, linting and shared settings
A team that argues about spaces and semicolons in code review spends less time on the bugs. This lesson shows how to move every style decision into tools: Prettier formats, ESLint catches mistakes, and the same rules run on save, before each commit and in CI.
By the end you can
- Explain the different jobs of Prettier, ESLint and EditorConfig, and why they must not overlap
- Write an ESLint flat config (
eslint.config.js) that works with Prettier - Commit
.vscode/settings.json,extensions.json, a task and a snippet so every teammate gets the same setup - Add a pre-commit hook with husky and lint-staged, and explain what it can and cannot guarantee
- Decide when a team needs profiles, Dev Containers or Remote-SSH
The everyday picture
Imagine every Mangrove store labelling its shelves its own way. In one store, rice is under "Grocery: Rice". In another it is a handwritten card that says "Rice and grains". In a third the label is on the back of the shelf. Each one works for the staff who made it. Then an area manager visits three stores in one day, or staff move between stores for a festival rush, and every visit starts with ten minutes of searching.
So head office prints one shelf-label standard and a label printer that applies it. Nobody debates font sizes at the morning meeting anymore, because the printer decides. Staff discuss what matters: what is out of stock, what is about to expire. A team's code is the same. When a tool formats every file the same way, nobody discusses spaces in review, and every file looks familiar to everyone.
Why style arguments are expensive
Style comments in code review cost more than they look. Each one interrupts the reviewer's attention for something no user will ever notice. Worse, mixed styles create noisy diffs. If one developer's editor uses tabs and another's uses two spaces, a one-line fix can show up as a 200-line change, and the real change hides inside it. Reviewers skim large diffs, and bugs pass.
The fix is to make style a decision the team makes once, written in config files in the repo, and enforced by tools that never get tired. Three tools share the work, and each has a different job:
- Prettier is a formatter. It reprints the whole file in one fixed style: line length, indentation, quotes, commas, semicolons. It has few options on purpose. It never changes what the code does.
- ESLint is a linter. It reads the code without running it and reports likely bugs: a variable that is never defined, a value that is never used,
==where you meant===. Some issues it can fix itself; most need a person. - EditorConfig is a small file,
.editorconfig, that tells any editor the basic whitespace rules: spaces or tabs, indent size, line endings, final newline. It helps for files Prettier does not touch and for teammates using other editors. Prettier also reads it, but its own config file wins.
Years ago ESLint also had style rules (indentation, quotes). If both tools fix the same thing differently, they fight on every save. The standard solution is eslint-config-prettier, which switches off every ESLint rule that Prettier handles. The Prettier team also recommends against running Prettier as an ESLint rule; it is slower and fills the editor with red lines for spacing. So: Prettier owns layout, ESLint owns correctness.
Quick check
Which tool tells you that a function uses a variable that was never defined?
Finding likely bugs is the linter's job; ESLint's no-undef rule reports it. Prettier only changes layout and would happily reformat broken code, and EditorConfig only sets whitespace rules.