How to Set Up VS Code for Web Development

A useful VS Code web-development setup is small, project-specific, and reproducible. Install the editor, add only extensions that solve a real problem, commit workspace settings when they benefit the team, and verify formatting, linting, terminal commands, and debugging on an actual project.

Start from a clean baseline

Download VS Code and open the project folder rather than individual files:

code path/to/project

Opening the folder gives VS Code a workspace root, so imports, source control, debugging paths, and project configuration resolve consistently. Keep the editor’s user preferences separate from repository settings that every contributor needs.

Step 1 — Install focused extensions

Open the Extensions view with Cmd/Ctrl + Shift + X. A practical starting set for JavaScript and TypeScript is:

Extension	Use it for
ESLint	Showing JavaScript and TypeScript lint errors in the editor.
Prettier - Code formatter	Applying the project’s formatting rules.
GitLens	Inspecting blame, history, and changes when the built-in Git view is not enough.
Path Intellisense	Completing file paths in imports.
Astro	Syntax support if the project uses Astro.

VS Code already includes strong support for many web languages, TypeScript, Git, search, and terminals. Avoid installing several extensions that format or lint the same file; competing formatters are a common source of confusing save behavior.

For a React project, a snippets extension can be convenient, but it is not a requirement for web development. Prefer the extensions recommended by the repository before adding personal preferences.

Step 2 — Configure editor defaults

Open the command palette with Cmd/Ctrl + Shift + P, then choose Preferences: Open User Settings (JSON). User settings are personal defaults:

{
  "editor.formatOnSave": true,
  "editor.tabSize": 2,
  "editor.insertSpaces": true,
  "files.trimTrailingWhitespace": true,
  "files.insertFinalNewline": true,
  "editor.rulers": [100],
  "editor.bracketPairColorization.enabled": true
}

Do not force a formatter globally if different projects use different conventions. When a repository includes a Prettier or ESLint configuration, select the project formatter from Format Document With… and choose Configure Default Formatter.

Step 3 — Add workspace settings

Repository-specific settings belong in .vscode/settings.json. A small example for a JavaScript project is:

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact"],
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true
  }
}

Commit workspace settings only when they are useful to the project as a whole. Do not commit machine-specific paths, personal terminal preferences, or settings that disable a repository’s checks. If a project already supplies .vscode/settings.json, extend it carefully instead of replacing it.

Step 4 — Use the integrated terminal

Open the terminal with Ctrl + ` or through Terminal: New Terminal. Select the correct shell with Terminal: Select Default Profile. The terminal should start in the workspace folder, where project scripts can run without manually changing directories:

npm install
npm run dev
npm run check

The JavaScript runtime and package manager must be installed separately. If that baseline is not ready, follow How to Set Up a Modern JavaScript Development Environment first.

Step 5 — Configure formatting and linting

Formatting and linting solve different problems:

• A formatter makes the code’s shape consistent.
• A linter catches suspicious patterns and project-specific mistakes.
• A type checker catches invalid values and interfaces in TypeScript projects.

Run the project’s own scripts before inventing new configuration:

npm run format
npm run lint
npm run typecheck

Not every project defines all three scripts. Check package.json, and do not treat a green editor status as a substitute for the CI command. For a typed project, see How to Set Up a TypeScript Project from Scratch.

Step 6 — Debug a Node program

Create .vscode/launch.json only if the project does not already provide one:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug current Node entry point",
      "program": "${workspaceFolder}/index.js",
      "skipFiles": ["<node_internals>/**"]
    }
  ]
}

Open Run and Debug, select the configuration, and press F5. Set a breakpoint by clicking beside a line number. Use F10 to step over, F11 to step into, and the debug console to inspect variables.

For a browser application, use the browser’s developer tools or the project’s documented VS Code browser-debugging configuration. Do not assume a Node launch configuration can debug client-side code.

Step 7 — Use Git without leaving the editor

The Source Control view can show diffs, stage individual hunks, and write commits, while the terminal remains useful for commands that need precision:

git status
git diff
git log --oneline -5

Review the diff before committing. Keep secrets, .env files, build output, and dependency directories out of version control. The Git and GitHub command-line guide covers authentication and the first-push workflow.

Shortcuts worth learning

Shortcut	Action
Cmd/Ctrl + P	Find and open a file quickly.
Cmd/Ctrl + Shift + P	Open the command palette.
Cmd/Ctrl + Shift + F	Search across the workspace.
Cmd/Ctrl + /	Toggle a line comment.
Alt/Option + Up/Down	Move a line.
Cmd/Ctrl + D	Select the next matching occurrence.
F5	Start debugging.

Keyboard shortcuts matter because navigation and search are used more often than extension-specific commands.

Troubleshooting

• Formatting does nothing — check the selected default formatter, the file language mode, and whether the project has a formatter configuration.
• The wrong formatter runs — use Format Document With…, then set the repository’s formatter as default for that language.
• ESLint reports nothing — confirm the ESLint extension is enabled for the language and run the project’s CLI script to see its real output.
• The debugger cannot start — verify that program points to a real file and that the launch configuration matches the runtime: Node, browser, or framework.
• Imports appear unresolved — open the repository root as the workspace and check the project’s TypeScript or bundler configuration.
• The terminal uses the wrong Node — compare node --version in VS Code’s terminal with the version in your normal shell.

Summary

A good VS Code setup provides predictable formatting, visible lint and type errors, a terminal rooted in the project, a debugger that matches the runtime, and a clean Git workflow. Keep the setup focused, commit team-wide workspace settings, and let each repository’s configuration remain authoritative.