•
binPath—Name and location of the sf binary.
•
cacheDir—Directory that Salesforce CLI uses for internal caching.
•
configDir—Directory in which Salesforce CLI stores internal configuration data.
•
dataDir—Directory in which Salesforce CLI stores data.
•
name—The npm name of Salesforce CLI, which is @salesforce/cli.
•
theme—The default color theme for --help messages.
•
shell—Shell you’re using, such as bash or zsh. The value is oclif’s best guess, but this information is notoriously difficult to
glean, so the value can be wrong or unknown, especially on Windows computers.
See the oclif documentation for more information.
pluginSpecificData
If you ran the doctor command with either the --command or --plugin flag, and the associated plugin is listening to the
doctor, then this section contains additional diagnostic information about the plugin. If the plugin isn’t listening, then this section is
empty.
By default, the doctor runs all diagnostic tests, including all plugin-defined tests. You can target tests for a specific plugin using the
--plugin flag as a way to reduce some noise or if you're a plugin author writing new doctor tests.
Debug Errors When Deploying or Retrieving Source
When you run project deploy start or project retrieve start, Salesforce CLI creates a temporary directory with
all the metadata files, and then deletes the directory upon successful completion of the command. If you run into errors when executing
either command, retaining these files can be useful for debugging purposes.
Sometimes you want to inspect the retained files even if you don’t run into an explicit error. Let’s say, for example, that your deployment
completes successfully, but when you check your org, the deployed components look different from what you expect. You can inspect
the metadata files before Salesforce sent them to the org and possibly find the problem. Similarly, if a retrieve completes successfully,
but the source files in your package directory aren’t what you expect, or something is missing, you can inspect the metadata format files
that were initially retrieved from the org, but before they were converted to source format.
How To Retain Temporary Metadata Files
To retain all the metadata files in a directory when you run the project deploy start and project retrieve start
commands, set the SF_MDAPI_TEMP_DIR environment variable to the directory path.
This example, run from a DX project directory, shows how to set the environment variable for a single retrieve.
SF_MDAPI_TEMP_DIR=mdapiout sf project retrieve start
When the command completes, the retained files are in a subdirectory of the mdapiout directory. The subdirectory’s name consists
of the timestamp when you ran the command, and either the suffix _retrieve or _deploy, depending on whether the command
was a retrieve or a deploy.
The format and location of the retained files depends on whether you ran a retrieve or a deploy:
•
For retrieves, the retained files are in both formats and in their own directories (metadata and source). The metadata directory
includes the downloaded metadata .ZIP file, the unzipped metadata format files, and the package.xml file.
The source directory contains the converted files in source format.
63
Debug Errors When Deploying or Retrieving SourceTroubleshoot Salesforce CLI