Salesforce Extensions for Visual Studio Code
Salesforce Extensions for Visual Studio Code is an open-source pack of extensions that turns VS Code into a full development environment for the Salesforce Platform.
Definition
Salesforce Extensions for Visual Studio Code is an open-source pack of extensions that turns VS Code into a full development environment for the Salesforce Platform. It bundles tools for writing Apex, Lightning Web Components, Aura, Visualforce, and SOQL, plus an Apex Replay Debugger, an Org Browser, and a deep connection to Salesforce CLI for retrieving and deploying metadata.
You install it from the Visual Studio Marketplace as the Salesforce Extension Pack. Behind the scenes it drives Salesforce CLI to talk to your orgs, scratch orgs, and sandboxes. It is the IDE Salesforce recommends for code-first development, and it replaced the retired Eclipse-based Force.com IDE.
What the Extension Pack actually installs and runs
The extensions inside the pack
The Salesforce Extension Pack is a meta-package. Installing it pulls in several focused extensions that each own one job. The core extension, salesforcedx-vscode-core, talks to Salesforce CLI and provides the SFDX commands you run from the Command Palette. The Apex extension adds syntax highlighting, code completion, and the test runner. Separate extensions cover Aura bundles, Visualforce pages, SOQL, and the Apex Replay Debugger. Newer additions handle Lightning Design System tokens, an Apex code analyzer, a Lightning Web Component preview, and a metadata visualizer. Salesforce also ships an Expanded pack that layers in third-party extensions many developers already use, like ESLint and Prettier configurations tuned for Salesforce projects. You do not wire these together by hand. The single pack listing in the marketplace installs the whole set and keeps them on compatible versions. If you ever need to disable one piece, each extension can be toggled independently, which is handy when one extension misbehaves and you want to isolate the cause.
Apex language support and the language server
Apex editing is powered by the Apex Language Server, which runs as a background process inside VS Code. It is what gives you IntelliSense: method and field suggestions, go-to-definition, find-all-references, hover documentation, and inline error squiggles as you type. Because the server reads your local source and the org metadata you have retrieved, completions reflect your real schema and custom classes, not a generic dictionary. This is why Apex support depends on a Java Development Kit being installed. Salesforce recommends JDK 21, and also supports JDK 17 and JDK 11. The language server needs that runtime to parse and index your Apex. The Apex extension also surfaces the test runner. You can run a single test method, a class, or the whole suite from CodeLens links above each test, then read pass and fail results plus coverage right in the editor. For a language with mandatory test coverage before deploys, having that loop one click away matters.
Retrieving and deploying metadata
Most of your day is moving metadata between your machine and an org. The pack gives you several ways to do it. Right-click a file or folder and choose Deploy Source to Org or Retrieve Source from Org. Run SFDX commands from the Command Palette for project-wide operations. Or use a package.xml manifest when you want precise control over what moves. Under the hood these actions call Salesforce CLI, which uses the Metadata API or the source-tracking APIs depending on your org type. Scratch orgs and sandboxes that support source tracking let the tools detect exactly what changed, so you push and pull deltas instead of full directories. For production and older sandboxes without tracking, you lean on manifests. The output channel logs every command, so when a deploy fails you can read the component-level errors and jump straight to the offending file. This tight retrieve-edit-deploy cycle is the heart of source-driven development on the platform.
The Org Browser
The Org Browser is a panel reached through a cloud icon in the Activity Bar. It lists the metadata types in your default org and the components under each type, without you writing a manifest first. Expand Custom Objects and you see fields with their data types. Expand Apex Classes and you see every class in the org. From there you retrieve a single component, or all components of a type, with one click. The source lands in your default package directory as set in sfdx-project.json. It also refreshes at several levels, org-wide, by type, by folder, or for one component, so you avoid hammering the API when you only need fresh copies of a few items. Folder-based types like Reports, Dashboards, Documents, and Email Templates are handled too. The Org Browser is the fastest way to pull metadata you did not author yourself, which is common when you join an existing org and need its Flows, layouts, or validation rules locally before you can change anything.
Apex Replay Debugger and SOQL Builder
Two tools stand out for everyday debugging and data work. The Apex Replay Debugger replays Apex execution from a debug log. You generate a log by running code or tests, then step through it inside VS Code. You set line breakpoints, inspect variable values, and walk the call stack after the fact, which is useful because you cannot always attach a live debugger to a transaction. It turns a wall of log text into an interactive session. The SOQL Builder gives you a form-based visual editor for queries. You pick an object, check the fields you want, add filters and ordering through the form, and watch the query text build as you click. When it runs you can save results to a .csv or .json file. For developers who do not write SOQL daily, or who want to explore an unfamiliar object, the builder removes guesswork about field API names and relationship syntax. Both tools ship inside the pack, so there is nothing extra to install.
Generative AI inside the editor
Recent versions add generative AI features through the Einstein extension included in the pack. The headline capabilities are natural language code generation, inline autocompletion for Apex and LWC, and test case generation for Apex classes. You describe what you want in a comment or prompt and the assistant drafts code in the editor, or it suggests the next lines as you type. The test generation feature reads an Apex class and proposes a test class, which gives you a starting point toward the coverage the platform requires before deployment. These features depend on your org and license setup, so availability varies, and the suggestions are drafts you review rather than finished code. Treat them as an accelerator, not an author. The point is that the same window where you edit, deploy, and debug now also helps you write, which keeps you in one tool instead of switching to a separate chat window and copying snippets back and forth.
Set up the Salesforce Extension Pack
Setting up the Salesforce Extension Pack takes a few prerequisites and one project step. Once it is in place you authorize an org and start retrieving metadata.
- Install the prerequisites
Install VS Code 1.90 or newer, a supported JDK (21 recommended, or 17 or 11), and Salesforce CLI. The CLI is required even if you never run it directly, because the extensions call it in the background.
- Add the Extension Pack
In the VS Code Extensions view, search for Salesforce Extension Pack and click Install. The single listing installs the whole set, including Apex, SOQL, Aura, Visualforce, and the Apex Replay Debugger.
- Create or open a project
Open the Command Palette and run SFDX: Create Project for a standard layout, or SFDX: Create Project with Manifest if you need a package.xml. Give it a name and pick a folder.
- Authorize an org
Run SFDX: Authorize an Org, choose the login URL, and complete the browser login. This sets your default org so deploy, retrieve, and the Org Browser know where to point.
Point the apex.java.home setting at a supported JDK if the language server cannot find one automatically; JDK 21 is the recommended runtime.
The base pack for everyday Apex, LWC, and metadata work. Start here unless you specifically want bundled third-party tooling.
Adds common third-party extensions used by Salesforce developers on top of the base set. Choose it if you want those preselected rather than installing them yourself.
- No JDK, or an unsupported one, breaks Apex IntelliSense and the test runner. The error usually points at the apex.java.home setting.
- The extensions need Salesforce CLI installed and on your PATH. A missing CLI shows up as commands failing immediately with a not-found error.
- Source tracking only works on scratch orgs and tracking-enabled sandboxes. For production, rely on a package.xml manifest and expect full retrieves rather than deltas.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Salesforce Extensions for Visual Studio Code.
- Org BrowserSalesforce
- Programming LanguagesSalesforce
Hands-on resources to go deeper on Salesforce Extensions for Visual Studio Code.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What are Salesforce Extensions for VS Code?
Q2. What replaces?
Q3. What key features does it include?
Discussion
Loading discussion…