The right VS Code extensions turn the editor from a plain text tool into a fully equipped development environment that sits at the center of your daily work. For years I have carried the same setup while switching between web, game server and bot projects; in this article I cover the extensions I actually use, the ones that visibly boost productivity, and why they earn their place. The goal isn't to list everything available but to show where each one fits in a real workflow.
Foundations first: making the editor effortless
Some extensions never draw attention, yet they smooth out every file you touch. These are the first ones I install when I join a project:
- EditorConfig for VS Code — If the repo has an
.editorconfigfile, it automatically applies indentation, line endings and character encoding. It's the lowest-cost way to keep everyone on the team writing in the same style. - Path Intellisense — Autocompletes folder structure as you type
importstatements and file paths, ending the minutes lost to a wrong path. - Code Spell Checker — Catches typos in variable names and comments. Writing
receiveinstead ofrecieveis a lifesaver when you grep for it later.
Formatting and linting: the duo that ends the debate
Keeping code style consistent by hand is wasted energy. To hand that job to tooling, the VS Code extensions I trust most are Prettier and ESLint:
- Prettier — Reformats your code to its own rules on save. It takes indentation, quotes and semicolons off the table entirely.
- ESLint — Flags real problems in JavaScript/TypeScript as you type, such as unused variables and undefined references. Prettier worries about format, ESLint about logic; the two work together.
To run Prettier automatically on save, I add this to my user or workspace settings:
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
}
}
Now every save formats the file and auto-fixes the issues ESLint can repair. If you want a language-specific formatter, you can configure it per file type with blocks like "[python]": { "editor.defaultFormatter": "..." }.
Managing Git without leaving the editor
VS Code's built-in Git support is good, but two extensions take it to another level:
- GitLens — Shows who changed each line, when and in which commit, right beside it (inline blame). When hunting down where a bug came from, you can browse file history, line history and commit details inside the editor.
- Git Graph — Draws branches, merges and the commit tree as a visual graph. Understanding the state before a tricky rebase or merge is far faster than reading the terminal.
These two shine in long-lived projects: looking at a line and answering "why did we do it this way" in seconds turns code archaeology into real work.
Remote and in-container development
When a big part of the work happens not on your local machine but on a VPS or inside a Docker container, Microsoft's Remote family becomes indispensable:
- Remote - SSH — Connect to a remote server over SSH and edit files as if they were local; extensions and the terminal run on the remote machine. Editing a game server or a Laravel setup directly on the VPS removes the hassle of copying files between local and remote.
- Dev Containers — Opens the project inside a container based on a
devcontainer.jsondefinition. Everyone on the team works with the same PHP/Node version and the same system dependencies, which largely ends "it worked on my machine" problems. - WSL — Connects directly to files inside the Linux subsystem on Windows. All three extensions share the same "Remote Explorer" model.
Language and framework-specific support
On top of the general extensions, it makes sense to add a few targeted ones based on your stack. The ones I reach for often:
- PHP Intelephense — Provides fast autocompletion, type hints and "go to definition" in Laravel and plain PHP projects.
- Tailwind CSS IntelliSense — Completes Tailwind class names and shows the generated CSS on hover.
- Docker — Offers syntax, autocompletion and container management for
Dockerfileandcomposefiles.
The principle here is to keep the base setup light and add the language extensions that genuinely add value to the project at hand. Too many overlapping extensions can slow the editor down, and two formatters doing the same job can conflict.
Keeping your setup portable
To choose your extensions once instead of installing them by hand on every machine, there are two approaches. VS Code's built-in Settings Sync syncs extensions, settings and keyboard shortcuts to an account. Alternatively, you can put project-specific recommendations in the repo:
// .vscode/extensions.json
{
"recommendations": [
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint",
"eamodio.gitlens"
]
}
Thanks to this file, everyone who opens the project sees which extensions are recommended and can install them in one click. For team consistency it's stronger than Settings Sync, because the recommendation is tied to the project, not the person.
Frequently Asked Questions
Do too many extensions slow VS Code down?
Yes, especially ones that activate on every launch and scan files in the background can slow startup. The Developer: Startup Performance command shows how long each extension spends, so you can disable the ones you don't use in specific workspaces.
Do Prettier and ESLint conflict with each other?
Not when configured correctly. If you turn off ESLint's formatting-related rules and leave formatting to Prettier, the two work cleanly together; the eslint-config-prettier package exists precisely to prevent that conflict.
Should I install extensions per workspace or globally?
Keep general tools (GitLens, Prettier) global; enable language extensions that only make sense in certain projects within that workspace. That way the editor carries only as much weight as you need in each project.
Want to speed up your own development workflow? I can help you set up a consistent toolchain and a clean workflow on a web, server or automation project — get in touch.