Salesforce Extensions for VS Code v67.12.1 Changes

Tooling updates slip breaking changes into workflows nobody has thought about in years. The v67.12.1 release of the Salesforce Extensions for VS Code consolidates command palette actions, changes how templates get populated, and confines the Apex Language Server to valid project boundaries.

If your team relies on standard keybindings, automation scripts, or polyglot repositories, several behaviors change here.

Consolidated Apex scaffolding and dynamic templates

Apex boilerplate used to come from static, hardcoded templates split across several commands. The dedicated SFDX: Create Apex Unit Test Class command (sfdx.force.apex.class.unit.test.create) is retired. Test class generation now sits inside SFDX: Create Apex Class.

Invoke the creation command and the extension pulls available templates from the runtime context, including any custom templates defined in your workspace.

SFDX: Create Apex Trigger gets the same treatment. Instead of a generic skeleton you wire up by hand, it prompts for the target sObject and trigger events upfront. Pick Case and before insert, before update and you get a structured entry point:

trigger CaseRoutingTrigger on Case (before insert, before update) {
    CaseRoutingHandler.run();
}

No cleaning up the trigger signature by hand, and handler delegation is in place from file creation.

Restricting Apex Language Server boundaries

In previous versions, opening an isolated .cls file outside a Salesforce project root started the Apex Language Server (LSP) daemon. That left unwanted .sfdx/tools/* directories and temporary metadata in arbitrary folders: the root of a polyglot monorepo, a patch extraction directory, wherever you were.

Starting with v67.12.1, the extension requires a valid sfdx-project.json file in the root workspace before activating the language client.

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true
    }
  ],
  "name": "core-crm",
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "61.0"
}

Without that file at the workspace root, the extension skips Java runtime verification (which requires JDK 17 or JDK 21) and leaves your folder structure alone.

Feature / behavior	Prior behavior	Behavior in v67.12.1	Impacted area
Test class command	Standalone Command Palette entry	Subsumed into Create Apex Class	Custom shortcuts, macros
Trigger scaffolding	Bare trigger skeleton	Upfront sObject and event prompt	File generation flow
Apex Language Server	Activated on any open .cls file	Requires root sfdx-project.json	Standalone script inspection
XML schema preference	Overwrote workspace setting	Configurable via explicit setting	Red Hat XML extension
Org Browser visibility	Actions visible in global context	Hidden outside DX projects	Command Palette clutter

Controlling XML schema tooltip suppression

Large Salesforce metadata files, a permission set with thousands of line items or a complex custom object, often lag the editor badly when the Red Hat XML extension tries remote XSD validation. The core Salesforce extension used to handle that by forcing xml.preferences.showSchemaDocumentationType to none on activation.

That has been corrected to respect existing user preferences, and a new setting governs schema inspection explicitly.

{
  "salesforcedx-vscode-core.metadata.doNotSuppressRedhatSchemaDocumentation": true,
  "xml.preferences.showSchemaDocumentationType": "hover"
}

Setting salesforcedx-vscode-core.metadata.doNotSuppressRedhatSchemaDocumentation to true stops the Salesforce extension from overriding your XML hover settings. Leave it at false, the default, if you work with large metadata files, so the editor UI thread does not freeze.

Custom class scaffolding for enterprise standards

Dynamic template resolution lets platform architecture teams standardize structural patterns across distributed teams. Instead of editing raw code after generation, a custom template carries the architecture with it: separation of concerns, fflib selectors, whatever your house standard is.

An enterprise selector template, for example, sits right in the class creation prompt:

public inherited sharing class AccountsSelector extends ApplicationSelector {
    public List<Schema.SObjectField> getSObjectFieldList() {
        return new List<Schema.SObjectField>{
            Account.Id,
            Account.Name,
            Account.AccountNumber,
            Account.AnnualRevenue
        };
    }

    public Schema.SObjectType getSObjectType() {
        return Account.SObjectType;
    }

    public List<Account> selectById(Set<Id> idSet) {
        return (List<Account>) selectSObjectsById(idSet);
    }
}

I have seen this catch integration regressions where developers scaffolded classes without inherited sharing and exposed internal data access across untrusted entry points.

What to watch for

• Broken custom keybindings. A local keybindings.json that references sfdx.force.apex.class.unit.test.create now throws a command not found error. Map those shortcuts to sfdx.force.apex.class.create instead.
• No code intelligence in standalone files. Opening a standalone .cls file to review a production snippet gets no syntax checking, outline view or symbol completion unless the file sits in a folder containing sfdx-project.json.
• XML editor performance. Setting salesforcedx-vscode-core.metadata.doNotSuppressRedhatSchemaDocumentation to true may degrade editor performance on large metadata files while schemas resolve over the network.
• Template validation. Custom templates with malformed parameters generate invalid source files, which then fail local source tracking or deployment validation.