VS Code + Salesforce Extension Pack: The Full Setup Guide

Most Salesforce developers install the Extension Pack, click through the defaults, and never touch it again. That's fine until something doesn't work — IntelliSense stops suggesting fields, deploy-on-save isn't deploying, the debugger won't attach — and there's no mental model of what's actually installed or how it's wired together.

Session 87 covers the full setup: what's actually in the pack, the one file that switches it on, authorizing orgs from inside the editor, Apex IntelliSense, the Replay Debugger, and the settings.json tweaks that make daily development noticeably faster.

What's actually in the Extension Pack

"Salesforce Extension Pack" isn't one extension — it's a bundle of six, installed together from the VS Code Marketplace:

• Salesforce CLI Integration — the core extension. Everything else depends on it. Wires the sf CLI into VS Code's command palette.
• Apex — IntelliSense, syntax highlighting, Go to Definition, and error checking for .cls and .trigger files, powered by the Apex Language Server.
• Apex Replay Debugger — step through a debug log inside the editor, no live session or special licence required.
• Visualforce — syntax support and IntelliSense for .page and .component files.
• Lightning Web Components — component scaffolding, HTML/JS IntelliSense, and preview support for LWC.
• SOQL — a visual, point-and-click query builder for .soql files, with live result previews against your authorized org.

Install it by searching "Salesforce Extension Pack" (publisher: Salesforce) in the VS Code Extensions panel. One install, all six extensions activate together.

The file that switches everything on

None of the extensions do much until VS Code recognises your folder as a Salesforce project — and that recognition depends entirely on one file existing at the project root: sfdx-project.json.

{
  "packageDirectories": [{ "path": "force-app", "default": true }],
  "sourceApiVersion": "61.0"
}

Without this file, IntelliSense won't activate, the Org Browser icon won't do anything useful, and deploy-on-save silently does nothing. If you cloned an existing Salesforce DX project, this file is already there. If you're starting fresh, generate one with sf project generate --name myproject, or create it by hand as shown above.

Authorizing an org from VS Code

You don't need to leave the editor to connect to an org. Open the Command Palette — Cmd+Shift+P on Mac, Ctrl+Shift+P on Windows — and run:

SFDX: Authorize an Org

Pick Production, Sandbox, or a Custom login URL, then give the connection an alias. A browser window opens for OAuth login; once you complete it, VS Code stores the session and the alias appears in the blue status bar at the bottom-left of the window. That status bar entry is always your current default org — click it to switch between authorized orgs without touching the command palette again.

Apex IntelliSense and Go to Definition

With the Apex extension active, VS Code gives you real autocompletion — method signatures, SObject fields, standard and custom classes — driven by the Apex Language Server rather than static snippets. Press F12 on any method or class reference and it jumps straight to the definition, including into managed package and standard library code where available.

If IntelliSense suddenly stops suggesting a field or object you just created, it's almost always a stale metadata cache. Run SFDX: Refresh SObject Definitions from the command palette, or enable the setting below so it happens automatically.

The Apex Replay Debugger

This is the most underused part of the pack. Rather than requiring a live, running transaction and a paid debugger licence, the Replay Debugger works entirely from a debug log:

1. Right-click a line number in your Apex code and choose SFDX: Toggle Checkpoint (you get up to 5 checkpoints).
2. Run SFDX: Update Apex Debug Log Levels to make sure checkpoints are captured at sufficient detail.
3. Trigger the code path in your org, then run SFDX: Get Apex Debug Logs and pick the relevant log.
4. Right-click the downloaded log and choose SFDX: Launch Apex Replay Debugger with Current File — it replays execution against your checkpoints with full variable inspection, exactly like a live debugger.

Because it replays a log instead of attaching live, it works in any org — including production, where live debugging usually isn't an option at all.

settings.json tweaks worth making

A handful of workspace or user settings noticeably change the day-to-day experience:

{
  "salesforcedx-vscode-core.push-or-deploy-on-save.enabled": true,
  "salesforcedx-vscode-core.retrieve-test-code-coverage": true,
  "salesforcedx-vscode-apex.enable-sobject-refresh-on-startup": true,
  "salesforcedx-vscode-core.show-cli-success-msg": false
}

push-or-deploy-on-save.enabled automatically pushes source to your default scratch org (or deploys to a sandbox) every time you save a file — no manual deploy command needed while iterating. retrieve-test-code-coverage highlights covered and uncovered lines directly in the editor after a test run. enable-sobject-refresh-on-startup keeps Apex IntelliSense aware of new custom fields and objects without a manual refresh every session. show-cli-success-msg: false just quiets the notification spam once you trust the workflow.

Where this gets you

None of this is complicated in isolation — it's the accumulation that matters. The Extension Pack installed, a valid sfdx-project.json, an authorized org, and a few settings.json tweaks turn VS Code from "an editor with some Salesforce icons" into an actual development environment: autocompletion that understands your org's metadata, one-command deploys on save, and a debugger that works without a live session or a special licence.