Salesforce DX Developer Guide

How Salesforce Developer Experience Changes the Way You Work
Project Setup
Authorization
Scratch Orgs
Development
Build and Release Your App
Develop Second-Generation Packages (Beta)
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Limitations for Salesforce DX

Here are some known issues you might run into while using Salesforce DX.

Salesforce CLI

Upgrade to High Sierra Breaks Salesforce CLI Installation
Description: After upgrading Mac OS X to High Sierra, the CLI installation breaks for Mac users that have used the .pkg installer to install the CLI.

Workaround: Before you uninstall and reinstall the CLI, see if this fix works from one of our amazing Salesforce Customer Trailblazers. See his blog for details.

If that doesn’t work, uninstall the CLI, then reinstall it.

If you choose to install using NPM, you don’t get the benefit of auto-updates. To uninstall the CLI if you used the DMG installer, download and run the GIST uninstall script: https://gist.github.com/dcarroll/318e5f2d44fb6c2e612dd8d817473cdb

Installation instructions: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_macos.htm

NPM installation instructions: https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_install_cli_npm.htm

Stacktrace May Occur When Upgrading the CLI from 5.7.6 to 6.0
Description: When upgrading the Salesforce CLI from version 5.7.6 to 6.0 by running sfdx update, you might see a stacktrace instead of this successful completion message:
1$ sfdx update

2sfdx-cli: Updating plugins... done

Workaround: This glitch is temporary. Rerun sfdx update.

Limited Support for Shell Environments on Windows
Description: Salesforce CLI is tested on the Command Prompt (cmd.exe), Powershell, and Windows Subsystem for Linux (WSL) for Ubuntu. There are known issues in the cygwin and Min-GW environments. These environments might be tested and supported in a future release. For now, use a supported shell instead.

Workaround: None.

The force:apex:test:run Command Doesn’t Finish Executing
Description: In certain situations, the force:apex:test:run command doesn’t finish executing. Examples of these situations include a compile error in the Apex test or an Apex test triggering a pre-compile when another is in progress.

Workaround: Stop the command execution by typing control-C. If the command is part of a continuous integration (CI) job, try setting the environment variable SFDX_PRECOMPILE_DISABLE=true.

Dev Hub and Scratch Orgs

Person Accounts Don’t Work in Developer Edition Scratch Orgs
Description: Person accounts work only in Enterprise Edition and Professional Edition scratch orgs.

Workaround: When working with person accounts, don’t use a DE scratch org.

Source Management

.forceignore Does Not Exclude Lightning Definition Bundle Files During a Push
Description: If you have added a file to a Lightning (Aura) Bundle folder that is not part of the bundle definition and try to exclude that file from push or packaging commands using .forceignore, the file isn’t ignored and an error is displayed.

See AuraDefinitionBundle for valid component types (bundle suffixes).

Workaround: Move the file from the aura directory to a different directory.

Must Manually Enable Feed Tracking in a Custom Object's Metadata File
Description: If you enable feed tracking on a custom object, then run force:source:pull, feed tracking doesn't get enabled.

Workaround: In your Salesforce DX project, manually enable feed tracking on the custom object in its metadata file (-meta.xml) like this: <enableFeeds>true</enableFeeds>.

force:mdapi:convert Returns a Success Exit Code Even When Conversion Fails
Description: If force:mdapi:convert fails for any reason and outputs an error message, the command still returns a 0 (Success) exit code.

Workaround: None.

Incorrect Status Message After Making a Fine-Grained Modification to a Custom Object
Description: Let’s say you make a fine-grained modification to a custom object in your scratch org, such as changing one of its field sets. When you run force:source:status or force:source:pull, the status message about the item you modified is sometimes incorrect. In our example, the field set might be marked as Remote Add even though it is already part of your source.

Workaround: None.

Pushing After Removing a Permission Set Locally Causes “Unknown” Error
Description: If you remove a permission set from your local project, then run the force:source:push command, you see the error message: Unknown.

Workaround: None.

Unable to Push Lookup Filters to a Scratch Org
Description: When you execute the force:source:push command to push the source of a relationship field that has a lookup filter, you sometimes get the following error:

duplicate value found: <unknown> duplicates value on record with id: <unknown> at line num, col num.

Workaround: None.

First-Generation Packaging

When You Install a Package in a Scratch Org, No Tests Are Performed
Description: If you include tests as part of your continuous integration process, those tests don’t run at the time when you install a package in a scratch org.

Workaround: You can manually execute tests after the package is installed.

New Terminology in CLI for Managed Package Password
Description: When you use the CLI to add an installation key to a package version or to install a key-protected package version, the parameter name of the key is --installationkey. When you view a managed package version in the Salesforce user interface, the same package attribute is called “Password”. In the API, the corresponding field name, “password”, is unchanged.

Workaround: None. The Password field name in the user interface will be changed in a future release.

Second-Generation Packaging

API Version Must be 41.0 or Later
Description: API versions before 41.0 aren’t supported for second-generation packages.

Workaround: Before you create a second-generation package, verify that you’ve set the sourceApiVersion in sfdx-project.json to 41.0 or later.

Unlocked and Locked Packages Can Only be Installed in Scratch or Sandbox Orgs
Description: You can create three types of second-generation packages. You can install managed second-generation packages in any org. Locked and unlocked packages are pilot features that you can install only in a sandbox or scratch org.

Workaround: None.

Unable to Specify a Patch Version
Description: The four-part package version number includes a patch segment, defined as major.minor.patch.build. However, you can’t create a patch for a second-generation package. Package creation fails if you set a patch number in the package descriptor. Stay tuned for patch versions in an upcoming release.

Workaround: Always set the patch segment of the version number, to 0. For example, 1.2.0.1 is valid but 1.2.1.1 is not.

Protected Custom Metadata and Custom Settings are Visible to Developers in a Scratch Org If Installed Packages Share a Namespace
Description: Use caution when you store secrets in your second-generation packages using protected custom metadata or protected custom settings. You can create multiple second-generation packages with the same namespace. However, when you install these packages in a scratch org, these secrets are visible to any of your developers that are working in a scratch org with a shared namespace. In the future, we might add a “package-protected” keyword to prevent access to package secrets in these situations.

Workaround: None.