7 VS Code Extensions I Can't Live Without

Introduction: Your Editor Is Your Workshop

A carpenter does not just grab any hammer. A chef does not cook with dull knives. And a software developer should not write code with a bare-bones editor. VS Code won the editor wars years ago, but the real magic lives in its extensions. The right set of extensions transforms VS Code from a text editor into a development environment that anticipates your needs.

I have tried hundreds of extensions over the years. Most are forgettable, some are actively harmful (hello, extensions that slow startup by 3 seconds), and a precious few are genuinely life-changing. After years of ruthless curation, these 7 extensions have earned permanent spots in my settings.json. They cover different aspects of the development workflow — code quality, navigation, debugging, collaboration, and aesthetics.

This is not a list of obscure gems nobody has heard of. Some of these are popular for a reason. But I am going to explain why each one matters, how I configure it, and the specific productivity gains I have measured. Let us get into it.

1. GitHub Copilot — Your AI Pair Programmer

Let us address the elephant in the room: AI-assisted coding is no longer optional. GitHub Copilot has evolved from "slightly smarter autocomplete" to a genuine thinking partner that understands context, patterns, and intent.

Why It Earns Its Spot

Copilot in 2026 is not the Copilot of 2022. The current model understands your entire codebase, not just the current file. It reads your imports, understands your type definitions, follows your naming conventions, and generates code that actually fits your project's style. The inline chat feature lets you describe what you want in plain English, and Copilot generates multi-file changes that you can review and apply with a single click.

How I Use It

• Boilerplate elimination — Writing repetitive code like API route handlers, test cases, or database queries? Copilot generates them from a single comment. I estimate it saves me 30-40 minutes per day on pure boilerplate.
• Learning new APIs — When working with an unfamiliar library, I type what I want to accomplish and Copilot suggests the correct API usage. It is like having the documentation embedded in my editor.
• Test generation — Write a function, then type // test on the next line. Copilot generates comprehensive test cases, including edge cases I might not have thought of.
• Explain and refactor — Highlight confusing code, ask Copilot to explain it, then ask it to refactor for clarity. This workflow is especially valuable when onboarding to legacy codebases.

Configuration Tips

Disable Copilot for sensitive files (environment variables, credentials) by adding patterns to your .copilotignore. Set the suggestion delay to 300ms if you find instant suggestions distracting. And always review generated code — Copilot is a junior developer with infinite typing speed, not an architect.

// .vscode/settings.json
{
  "github.copilot.editor.enableAutoCompletions": true,
  "github.copilot.enable": {
    "plaintext": false,
    "markdown": true,
    "yaml": true
  }
}

2. ESLint — The Ruthless Code Quality Guardian

ESLint is not exciting. It does not have a beautiful UI or flashy animations. It just quietly prevents you from shipping bugs, and that makes it indispensable.

Why It Earns Its Spot

The ESLint VS Code extension does not just show red squiggly lines. It provides real-time feedback as you type, catches bugs before they reach the browser, enforces your team's coding standards, and auto-fixes hundreds of common issues on save. Without ESLint, code reviews devolve into debates about semicolons and import ordering. With ESLint, those debates happen once — when you configure the rules — and then the machine enforces them forever.

The Rules That Actually Matter

Most teams over-configure ESLint. Here are the rules that provide the highest value with the lowest noise:

• no-unused-vars — Dead code is tech debt. Remove it immediately.
• no-console (with warnings) — console.log statements should not make it to production.
• prefer-const — If you do not reassign it, declare it as const. This communicates intent.
• no-implicit-coercion — Explicit is better than implicit. Always.
• @typescript-eslint/no-explicit-any — The any type defeats the purpose of TypeScript. Restrict it aggressively.
• import/order — Consistent import grouping (built-ins, external, internal, relative) makes files scannable.

The Flat Config Era

ESLint 9+ uses the new flat config format (eslint.config.js instead of .eslintrc). If you have not migrated, do it now. The new format is simpler, more predictable, and eliminates the cascade confusion of the old config inheritance model. The VS Code extension fully supports flat config as of mid-2025.

3. Prettier — One Formatter to End All Arguments

Prettier is not a linter. It does not tell you if your code is correct. It tells you exactly how your code should look, and it enforces that formatting automatically. This distinction matters.

Why It Earns Its Spot

Before Prettier, every team had "the tabs vs spaces debate." Every code review included comments about line length, bracket placement, and trailing commas. Prettier ends all of that. You configure it once, enable format-on-save, and never think about formatting again. Your code looks the same whether it was written by a 20-year veteran or a day-one intern.

My Configuration

// .prettierrc
{
  "semi": true,
  "singleQuote": false,
  "tabWidth": 4,
  "trailingComma": "es5",
  "printWidth": 100,
  "bracketSpacing": true,
  "arrowParens": "always"
}

The key settings to decide early: printWidth (I use 100, some teams prefer 80 or 120), singleQuote (depends on your ecosystem — React projects tend toward double quotes), and tabWidth (2 for frontend, 4 for backend is a common convention). Pick values, commit the config, and move on forever.

Prettier + ESLint: The Integration

Use eslint-config-prettier to disable ESLint rules that conflict with Prettier. Let Prettier handle formatting and ESLint handle logic. This clean separation prevents the tools from fighting each other and gives you the best of both worlds.

4. GitLens — Git Superpowers Inside Your Editor

Git is essential but its command-line interface is hostile. GitLens brings the full power of Git directly into your editor, making version control visual, contextual, and fast.

Why It Earns Its Spot

GitLens adds inline blame annotations showing who changed each line and when. It gives you a visual file history, interactive rebase tools, branch comparison views, and commit searching. But its real superpower is context. When you are staring at a confusing piece of code, GitLens tells you who wrote it, when it was last modified, what PR it was part of, and what the commit message said. That context is often the difference between understanding the code and spending an hour reverse-engineering it.

Features I Use Daily

• Inline blame — See the author and commit at the end of each line. I can instantly tell if code was written recently (and is thus more likely to be correct) or is legacy (and might need scrutiny).
• File history — Visual timeline of every change to a file. Invaluable when debugging regressions — you can see exactly which commit introduced a change.
• Branch comparison — Compare your current branch against main/develop to see all differences. Much more intuitive than git diff output.
• Stash management — Visual stash list with the ability to apply, pop, or drop stashes. No more forgetting what you stashed three days ago.
• Worktree support — Manage multiple Git worktrees directly from the sidebar. Essential for working on multiple features simultaneously without stashing.

Performance Note

GitLens can slow down VS Code in very large repositories (100K+ files). If you experience lag, disable the "Current Line Blame" feature and use the blame sidebar instead. You can also configure GitLens to ignore certain large or binary files.

5. Thunder Client — REST API Testing Without Leaving Your Editor

Postman is a great tool. It is also a separate application, requires account creation, and has become increasingly bloated with features most developers never use. Thunder Client does 90% of what Postman does, directly inside VS Code.

Why It Earns Its Spot

When developing APIs, the feedback loop matters. Open Postman, switch windows, create a request, switch back to fix the code, switch back to Postman, re-run the request... Or just press a keyboard shortcut in VS Code, fire the request, see the response, fix the code, and re-run — all without leaving your editor. That tight feedback loop is worth the trade-off of slightly fewer features.

Features That Make It Work

• Collections — Organize requests by project or feature. Share collections via Git by committing the thunder-tests folder.
• Environment variables — Switch between dev, staging, and production environments with a dropdown. Variables are interpolated in URLs, headers, and body.
• Request chaining — Use the response from one request as input to another. Log in, capture the token, use it in subsequent authenticated requests — all automated.
• Code generation — Generate fetch/axios/curl code from any request. Useful for translating manual testing into actual application code.
• GraphQL support — Full GraphQL query support with syntax highlighting and variable management.

When to Use Postman Instead

If you need advanced features like mock servers, API monitoring, or team collaboration with role-based access, Postman is still superior. Thunder Client is for individual developers who want fast, focused API testing without context-switching.

6. Error Lens — Make Errors Impossible to Miss

By default, VS Code shows errors as squiggly underlines. You have to hover over them to read the message, or check the Problems panel. Error Lens takes those errors and displays them inline, right next to the offending code, in bright impossible-to-miss colors.

Why It Earns Its Spot

It sounds like a small thing, but it fundamentally changes how you interact with errors. Instead of coding for 10 minutes, running the build, seeing 15 errors, and scrolling through the Problems panel — you see errors as you create them. The feedback is instantaneous and spatial. The error appears right where the problem is, so your eyes never leave the relevant code.

Configuration for Sanity

Out of the box, Error Lens can be visually overwhelming. I recommend these settings:

{
  "errorLens.enabledDiagnosticLevels": ["error", "warning"],
  "errorLens.delay": 500,
  "errorLens.messageMaxChars": 120,
  "errorLens.fontStyleItalic": true,
  "errorLens.gutterIconsEnabled": true
}

Disabling "info" and "hint" levels keeps the visual noise manageable. The 500ms delay prevents flickering while you are mid-keystroke. And limiting message length prevents long TypeScript errors from wrapping across your entire screen.

7. Todo Tree — Never Lose a TODO Again

Every developer writes // TODO: comments with the best intentions. "I'll come back to this." "Fix this before shipping." And then those TODOs accumulate, forgotten, until someone discovers them in a code review three months later. Todo Tree makes sure that never happens.

Why It Earns Its Spot

Todo Tree scans your entire codebase for TODO, FIXME, HACK, BUG, and other configurable tags, then displays them in a searchable tree view in the sidebar. You get a bird's-eye view of every outstanding task, organized by file and tag type. It is like having a project-wide issue tracker embedded in your editor.

Custom Tags I Use

{
  "todo-tree.general.tags": [
    "TODO",
    "FIXME",
    "HACK",
    "BUG",
    "PERF",
    "NOTE",
    "REVIEW"
  ],
  "todo-tree.highlights.customHighlight": {
    "BUG": { "icon": "bug", "foreground": "#FF2D00" },
    "FIXME": { "icon": "flame", "foreground": "#FF8C00" },
    "PERF": { "icon": "zap", "foreground": "#FFD700" },
    "REVIEW": { "icon": "eye", "foreground": "#7B68EE" }
  }
}

• TODO — Standard task to complete later
• FIXME — Something broken that needs attention
• HACK — Temporary workaround that should be replaced
• BUG — Known bug that needs fixing
• PERF — Performance improvement opportunity
• REVIEW — Needs code review or discussion

The key insight is using different tags for different severities. A TODO is a nice-to-have. A FIXME is urgent. A BUG needs immediate attention. Color-coding them in the tree view makes triage instant.

Honorable Mentions

These did not make the top 7 but deserve recognition:

• Auto Rename Tag — Rename an HTML/JSX opening tag and the closing tag updates automatically. Simple and saves hundreds of keystrokes.
• Import Cost — Shows the size of imported packages inline. Great for keeping bundle sizes in check.
• Bracket Pair Colorizer — Now built into VS Code natively, but worth enabling if you have not already.
• vscode-icons — File-type-specific icons in the explorer. Makes navigating large projects significantly faster.
• REST Client — Alternative to Thunder Client that uses .http files. More "code-like" but less visual.

Setting Up Your Extensions: The Right Way

Do not just install these extensions and use default settings. Take 30 minutes to configure them properly:

1. Create a workspace .vscode/extensions.json — List recommended extensions so new team members get prompted to install them.
2. Commit your .vscode/settings.json — Share editor configuration with the team. Formatters, linters, and code actions should be consistent across all machines.
3. Use profiles — VS Code profiles let you maintain separate extension sets for different types of projects (frontend, backend, DevOps). Switching profiles is instant.
4. Audit startup performance — Run Developer: Show Running Extensions and sort by activation time. Disable anything taking more than 100ms that you do not use daily.

Conclusion: Invest in Your Tools

Your editor is where you spend 6-8 hours every day. A 5% improvement in editor efficiency compounds into hundreds of hours saved per year. These 7 extensions — Copilot, ESLint, Prettier, GitLens, Thunder Client, Error Lens, and Todo Tree — represent thousands of collective hours of development, and they are all free (Copilot has a free tier for individual developers).

Install them, configure them thoughtfully, and then forget about them. The best tools are the ones that fade into the background, quietly making you faster without demanding your attention. That is the mark of a well-crafted development environment.