Static analysis for your Salesforce git repository
npm install dx-copnpm install --global sfdx-cli
sfdx plugins:install dx-cop
sfdx dxcop:source:check
sfdx dxcop:source:check --json
--help to view these).
.dxcoprc configuration file, in JSON format, can be used to enable/disable individual rulesets. Create this file in the base folder of your Salesforce project, with the following format:
{
"ruleSets": {
"adminProfile": { "enabled": false },
"emailToCaseSettings": { "enabled": true },
"installedPackages": { "enabled": true },
"lightningWebComponents": { "enabled": true },
"minimumAccessProfile": { "enabled": false, "profileName": "Minimum Access - Salesforce" },
"queues": { "enabled": false },
"recordTypePicklists": { "enabled": true },
"recordTypePicklistValues": { "enabled": true }
}
}
`
$3
If the config file doesn't exist, the settings in the example above are used. The config file may also be incomplete; if any parts of it are missing, the default values are substituted in.
Rulesets
A ruleset is a collection of closely-related rules that are run together. There are currently a small number of rulesets, but the list is growing.
$3
All objects and fields should be fully accessible to the System Administrator profile, e.g. for debugging & troubleshooting purposes. This ruleset ensures that:
- there is an entry in the Admin profile for every object
- includes standard objects, custom objects, custom metadata types and external objects
- there is a entry in the Admin profile for every _custom_ field
- note: this rule currently does not check standard fields
- every entry and every entry has all permissions set to true
- are sorted alphabetically by object name
- are sorted alphbetically by field name
$3
Ensures you don't have the and fields stored in version control. These are specific to each environment and usually cause validation failures if you try to change them in a deployment, so it's best not to store them at all.
Also ensures that are ordered by .
$3
A common problem when retrieving Installed Packages is that they contain , which fails to deploy since is a required field. It must be explicity set e.g. to . This ruleset will report the problem early, to avoid failed deployments.
$3
Checks *.js-meta.xml files for extra whitespace at the ends of lines. This can cause unexpected behaviour when you retrieve the same component after deployment; extra lines of whitespace can be inserted resulting in unexpected file differences.
$3
The Minimum Access profile should not have access (read, edit, delete, etc) to _any_ objects or fields. Access should be controlled via permission sets instead. This ruleset will raise a warning if any or elements in the Minimum Access profile are true.
By default the "Minimum Access - Salesforce" profile will be examined. This can be changed in the config file.
$3
When you add a new picklist field to an object, Salesforce automatically adds a reference to that picklist to the metadata for every record type. This check ensures you remember to add the record type changes to git as well.
$3
Examines record types & checks for picklist values that don't exist (or are inactive) in the corresponding picklist field definitions.
$3
Examines queues & raises warnings if any contain users as direct members. This can lead to deployment failures if users don't exist in target environments. Preferred approach is to use public groups or roles for queue membership.
Problem categories
$3
Metadata Errors are conditions that would in all likelihood prevent a component from being deployed, due to a Salesforce validation error. This tool does not aim to find all validation errors; rather it focuses on the ones that can be easily missed, only to surface later. e.g. when a record type references a picklist value that no longer exists.
$3
Metadata Warnings are conditions that usually don't result in a validation/deployment errors, but could still cause problems later. Often the result of a new component causing changes to other components, but only the first component is committed to git. The potential 'later' problems could include:
- merge conflicts
- config intended by the developer is missed
- unexpected differences when retrieving components from an org
Limitations
$3
The most notable limitation is that currently, multiple packages are not supported. Only the default package according to your sfdx-project.json` is examined.