Author(s): Ray Hu

Originally published on Towards AI.

5 .vscode Files That Standardize Your Whole Team

Here’s a moment every developer on a team has lived through. A new hire clones the repo, opens it, and spends the first half of their day hunting down the right extensions. Someone saves a file and the diff explodes because their indentation settings don’t match yours. Two people describe the “correct” way to attach a debugger and neither one agrees.

The root cause is almost always the same: everyone’s editor is configured in isolation. And when your team has standardized on VS Code, there’s a cheap, built-in fix sitting right in your project root — the unassuming .vscode folder.

One caveat up front. Everything here only applies to VS Code. If your team runs a mix of WebStorm, Sublime, and others, .vscode is invisible to them — you'll want EditorConfig and Prettier to carry consistency across editors. This approach shines when everyone is on VS Code.

Why .vscode Belongs in Git

.vscode is VS Code's workspace configuration directory. Open a folder in VS Code and the editor automatically reads whatever lives in there, treating it as the highest-priority setting for that project — it overrides your personal global preferences. Think of it as a runtime manual for the project that tells everyone who opens it:

• Which extensions and formatters to use
• What to auto-fix on save
• How to start a debug session with one key
• Which common commands are one click away

Because those settings directly shape both collaboration and code quality, you should commit .vscode to version control (sensitive paths aside). Clone the repo, and the editor instantly knows the project's conventions.

Let’s walk through the five files that do the heavy lifting.

1. settings.json — One Editor Behavior for Everyone

This is the heart of your workspace config. It should hold only rules that are tightly coupled to the project — never personal taste like font size or color theme.

A typical front-end setup (React + TypeScript + ESLint + Prettier):

{
 // --- Formatting & auto-fix ---
 "editor.formatOnSave": true,
 "editor.defaultFormatter": "esbenp.prettier-vscode",
 "editor.codeActionsOnSave": {
 "source.fixAll.eslint": true
 },
 
 // Pin a formatter per language to avoid plugin conflicts
 "[javascript]": {
 "editor.defaultFormatter": "esbenp.prettier-vscode"
 },
 "[typescriptreact]": {
 "editor.defaultFormatter": "esbenp.prettier-vscode"
 },
 
 // --- File & search hygiene ---
 "files.exclude": {
 "node_modules": true,
 "dist": true,
 ".next": true
 },
 "search.exclude": {
 "pnpm-lock.yaml": true,
 "package-lock.json": true
 },
 
 // --- TypeScript ---
 "typescript.tsdk": "node_modules/typescript/lib",
 "typescript.enablePromptUseWorkspaceTsdk": true
}

One gotcha worth flagging: source.fixAll.eslint must be true to auto-fix on save. Set it to "explicit" and you'll have to trigger the fix manually — don't mix the two and expect consistent behavior.

2. extensions.json — Everyone's Extensions in One Click

Your project needs specific extensions — Prettier, ESLint, the Tailwind plugin. Declare them here, and anyone who opens the project gets a prompt to install the whole set at once.

{
 "recommendations": [
 "esbenp.prettier-vscode",
 "dbaeumer.vscode-eslint",
 "bradlc.vscode-tailwindcss",
 "ms-vscode.vscode-typescript-next",
 "csstools.postcss"
 ],
 "unwantedRecommendations": [
 "hookyqr.beautify",
 "octref.vetur"
 ]
}

The rule of thumb: only recommend what the project actually needs to run. unwantedRecommendations is just as useful — it steers people away from plugins that conflict, like an old formatter fighting with Prettier.

3. launch.json — Debugging You Can Just Press F5 On

Front-end debugging means launching browsers, attaching to Node processes, wiring up source maps. Stitching that together by hand is a tax nobody should pay twice. launch.json turns it into a single keystroke.

A full-stack React / Next.js example:

{
 "version": "0.2.0",
 "configurations": [
 {
 "name": "Launch Chrome",
 "type": "chrome",
 "request": "launch",
 "url": "http://localhost:3000",
 "webRoot": "${workspaceFolder}/src"
 },
 {
 "name": "Next.js: debug server-side",
 "type": "node",
 "request": "launch",
 "runtimeExecutable": "npm",
 "runtimeArgs": ["run", "dev"],
 "port": 9229,
 "env": { "NODE_OPTIONS": "--inspect" }
 }
 ],
 "compounds": [
 {
 "name": "Full Stack Debug",
 "configurations": ["Next.js: debug server-side", "Launch Chrome"],
 "stopAll": true
 }
 ]
}

That compounds block is the payoff: one entry that boots the server and the browser debugger together. A few variables you'll reach for constantly — ${workspaceFolder} for the project root, ${file} for the current file, ${relativeFile} for its workspace-relative path.

4. tasks.json — Common Scripts, One Command Away

tasks.json surfaces your package.json scripts as clickable tasks — and can even chain them into debugging ("start the dev server before we attach").

{
 "version": "2.0.0",
 "tasks": [
 {
 "label": "dev server",
 "type": "npm",
 "script": "dev",
 "isBackground": true,
 "problemMatcher": {
 "pattern": { "regexp": "" },
 "background": {
 "activeOnStart": true,
 "beginsPattern": "Compiling...",
 "endsPattern": "Compiled successfully|Failed to compile"
 }
 }
 },
 {
 "label": "type-check",
 "type": "shell",
 "command": "npx tsc --noEmit",
 "problemMatcher": "$tsc",
 "group": "test"
 }
 ]
}

Reference "preLaunchTask": "dev server" from launch.json and VS Code spins the server up automatically before every debug session.

5. snippets — Project-Level Code Templates

You can also drop snippet files into .vscode — say react.code-snippets — so everyone scaffolds boilerplate the same way.

{
 "React Functional Component": {
 "prefix": "rfc",
 "body": [
 "import React from 'react';",
 "",
 "interface ${1:Props} {",
 " $0",
 "}",
 "",
 "export const ${2:Component}: React.FC<${1:Props}> = (props) => {",
 " return <div>${2:Component}</div>;",
 "};"
 ],
 "description": "React functional component template"
 }
}

Now typing rfc produces a component skeleton that matches the project's conventions — far more consistent than everyone's personal snippet library.

Best Practices and the Traps to Avoid

Keep it minimal and explainable. Every rule in settings.json should earn its place. If a setting is pure personal preference ("editor.fontSize": 14), move it to your global user config. When a choice isn't obvious, leave a comment explaining why.

Stay aligned with your toolchain. Task labels in tasks.json must match package.json exactly. Formatters and rules in settings.json should echo your .eslintrc and .prettierrc, so the editor and CI never disagree.

A few failure modes that trip people up constantly:

• Recommended extensions installed, but formatting still doesn’t fire. Usually two formatters are fighting. Pin editor.defaultFormatter explicitly, then override it inside each language block.
• Background tasks that never terminate. Check that your beginsPattern / endsPattern regexes actually match the real terminal output. Set "problemMatcher": [] first just to confirm the task runs at all.
• source.fixAll.eslint doing nothing. Make sure the ESLint extension is enabled and a valid config lives at the project root. Since VS Code 1.74, some code actions must be set to true, not the string "explicit".

The Takeaway

The .vscode folder is a small, precise piece of modern front-end engineering — but its whole power rests on one condition: the team is unified on VS Code. Given that, it promotes editor config from a personal choice to a project asset, standardizing debugging, formatting, and snippets so your team burns far less time on setup and "works on my machine" archaeology.

Next time you spin up a project or inherit an old repo, spend ten minutes on .vscode. Your teammates will quietly thank you.

If this saved you a setup headache, a clap 👏 (or fifty) helps other developers find it. And drop your favorite .vscode trick in the comments — I read every one.

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI