Git Course 0%

Recommended extensions

Beginner VS Code UI ≈ 6 min

Before this lesson

What you will learn

  • Which extensions actually earn their place
  • How a repository recommends extensions to everyone who opens it
  • How to keep the set small

After this lesson you can

  • I have a short, useful set installed rather than forty

Why this matters

VS Code without extensions already does everything in this section. Extensions add the platform features and a few genuine conveniences, and a small set kept deliberately beats a large set accumulated.

The ones worth having

Extension Adds For whom
GitLab Workflow Merge requests, issues, pipelines, .gitlab-ci.yml validation GitLab users
GitHub Pull Requests and Issues Pull requests, issues, review in the editor GitHub users
GitLens Inline blame, richer history, file and line annotations Anyone who asks "why is this line like this?"
Markdown All in One Table of contents, list continuation, shortcuts, preview improvements Anyone writing documentation
markdownlint The same rules the pipeline runs, shown while you type Anyone whose project lints Markdown
Code Spell Checker Spelling in prose and in code comments, with a project dictionary Everyone, honestly
EditorConfig for VS Code Applies the project's .editorconfig Anyone in a project that has one

Two notes. GitLens is powerful and its default configuration is busy; turning off most of its inline decorations and keeping the blame on hover is a good starting point. And markdownlint paired with the project's own configuration file is the single best way to stop a pipeline failing on heading levels, because you see the same warning as you type (lesson 14.7).

What the editor already does

Worth knowing so you do not install something for it:

  • Git: staging, committing, branches, history, stashes, the merge editor. All built in.
  • Markdown preview: ⌘K V opens a live preview beside the file. Built in.
  • File history: the Timeline view in the Explorer. Built in.
  • A commit graph: the Source Control Graph. Built in.

Project recommendations

A repository can suggest extensions to everyone who opens it, in .vscode/extensions.json:

.vscode/extensions.json
{
  "recommendations": [
    "eamodio.gitlens",
    "davidanson.vscode-markdownlint",
    "streetsidesoftware.code-spell-checker",
    "editorconfig.editorconfig"
  ]
}

VS Code shows a notification offering to install them. This is a small, high-value contribution to a project: it means the next person to join sees the same warnings as everyone else, without being told.

The same folder can hold settings.json for shared settings (lesson 15.1), which pairs naturally with the linting extensions.

Keeping it small

Every extension has a cost: startup time, occasional conflicts, and one more thing that can behave oddly. Two habits keep it manageable:

  • Profiles: Command Palette → Profiles: Create Profile keeps a documentation profile separate from, say, a Python profile, each with its own extensions.
  • A periodic look: Extensions: Show Installed Extensions, and uninstall anything you cannot remember choosing.

How to do it

Extensions can be installed from the command line, which is how a team script sets up a new machine:

Terminal
$ code --install-extension davidanson.vscode-markdownlint
$ code --list-extensions

Common mistakes

  • Installing an extension for something built in, such as Markdown preview or a commit graph.
  • Leaving GitLens at its default settings, which decorates every line and quickly becomes noise.
  • Forty extensions, three of which are used.
  • Recommending extensions without the matching configuration, so everyone sees different warnings.
  • Trusting an unfamiliar extension with repository access. Check the publisher and the install count.

Try it yourself

Goal: a small, deliberate set, shared with the project.

  1. Open the Extensions view and list what you have installed.
  2. Uninstall anything you cannot explain in one sentence.
  3. Install the linter your project's pipeline uses, and confirm it warns on a deliberate mistake.
  4. Add .vscode/extensions.json to your practice project recommending it, and commit.
  5. Close and reopen the folder, and confirm the recommendation notification appears.

Expected result: the editor warns you about the same things the pipeline does, and anyone who opens the project is offered the same setup.

Show solution

Step 3 is the one that pays off daily. A linting extension reading the project's own configuration turns a ten-minute pipeline round trip into a squiggly underline while you type, which is the same argument as running the pipeline's commands locally, made automatic.

Check yourself

1. Which of these does VS Code already do without an extension?
2. What does .vscode/extensions.json do?
3. Why install the same linter your pipeline runs?

Key terms

Editor Markdown IDE

Related