Salesforce Extensions for VS Code v67.12.1 Changes

Developer tooling updates often introduce subtle breaking changes into daily development workflows. The v67.12.1 release of the Salesforce Extensions for VS Code consolidates command palette actions, changes how templates are populated, and strictly isolates the Apex Language Server to valid project boundaries.

If your team relies on standard keybindings, automation scripts, or polyglot repositories, several operational behaviors change with this version.

Consolidated Apex Scaffolding and Dynamic Templates

Creating Apex boilerplate previously relied on static, hardcoded templates split across multiple commands. The dedicated command SFDX: Create Apex Unit Test Class (sfdx.force.apex.class.unit.test.create) has been retired. Test class generation is now integrated directly into SFDX: Create Apex Class.

When invoking the creation command, the extension dynamically surfaces available templates from the runtime context, including custom templates defined in your workspace.

Similarly, SFDX: Create Apex Trigger no longer creates a generic skeleton requiring manual event setup. It prompts for the target sObject and trigger events upfront. For example, selecting Case and before insert, before update generates a structured entry point:

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

This flow avoids manual trigger signature cleanup and enforces clean handler delegation from the initial file creation.

Restricting Apex Language Server Boundaries

In previous versions, opening an isolated .cls file outside a Salesforce project root triggered the Apex Language Server (LSP) daemon. This generated unwanted .sfdx/tools/* directories and temporary metadata inside arbitrary folders, such as root directories in polyglot monorepos or patch extraction directories.

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 this file at the workspace root, the extension bypasses Java runtime verification (which requires JDK 17 or JDK 21) and leaves the folder structure untouched.

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—such as permission sets containing thousands of line items or complex custom objects—often create severe editor lag when the Red Hat XML extension attempts remote XSD validation. To mitigate this, the core Salesforce extension historically forced xml.preferences.showSchemaDocumentationType to none upon activation.

This behavior has been corrected to respect existing user preferences, alongside a new setting to govern 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. Keep this set to false (the default) if you work with large metadata files to prevent editor UI thread freezes.

Custom Class Scaffolding for Enterprise Standards

Dynamic template resolution allows platform architecture teams to standardize structural patterns across distributed teams. Rather than modifying raw code after generation, custom templates can enforce architectural structures like separation of concerns or fflib selectors.

An enterprise selector template, for example, can be exposed directly through 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 prevent integration regressions where developers inadvertently scaffolded classes without inherited sharing, exposing internal data access across untrusted entry points.

What to Watch For

• Broken Custom Keybindings: If your local keybindings.json references sfdx.force.apex.class.unit.test.create, that shortcut will now throw a command not found error. Map your shortcuts to sfdx.force.apex.class.create instead.
• No Code Intelligence in Standalone Files: Opening a standalone .cls file to review a production snippet will not trigger syntax checking, outline views, or symbol completion unless opened inside 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 that introduce malformed parameters will generate invalid source files, which will fail during local source tracking or deployment validation.