Get your #buildspiration from the Summer ’19 release! We are sharing five of our favorite release features for Developers (and Admins) as part of the The MOAR You Know learning journey. Get the release highlights as curated and published by our evangelists. Complete the trailmix by July 31, 2019, to get a special community badge, and unlock a contribution of $10 to FIRST.

Summer is here and along with it comes a host of new developer features and goodies, including updates to the Salesforce CLI. Here’s a quick round-up to catch you up on some of the coolest new CLI features.

While this blog post is part of our round up of Summer ’19 features, it’s worth noting the CLI actually gets new features weekly. Some of the features I’ll talk about are actually available today in the CLI as they came out as part of the weekly release cycle.

In the case that a feature is part of the actual Summer ’19 pre-release cycle, you will need to update your CLI to pre-release (v46). Instructions for switching back and forth between pre-release and GA versions of the CLI are found on the Salesforce CLI release notes page.

More friendly project bootstrapping

For the past few months, the CLI has been able to set up a project that has a number of enhanced features for developing your Lightning Platform app. However, the enhanced features had to be selected explicitly as a parameter when you created a project by running force:project:create --template standard (the default was empty).

If you’ve been keeping your VSCode plugin for Salesforce DX up to date, you may have already noticed the change. But in Summer ’19, anytime force:project:create is run, by default your project will have these enhanced features. These include things such as:

• additional metadata file directories in your source tree
• a .gitignore file to flag files to not commit to version control
• config files to enable use of the Prettier code formatter for LWC and Aura
• a config file to run the Apex replay debugger in VS Code
• a config file to enable deploy on save functionality in VS Code
• a config file to enable VS Code to prompt you for the best extensions to run
• a README that includes more details about the difference between package-based and org-based development and instructions for project setup for each

While technically you need the pre-release version of the CLI to get the automatic default value, recall all you need to do is add the --template standard flag in the current GA version of the CLI.

There’s another nice feature if you work in an org-based development project (in other words, committing to and retrieving from Sandbox, Developer Edition, or other non-scratch orgs). When you create your project, you can have force:project:create scaffold a basic package.xml manifest file. Simply add the --manifest or -x parameter to the command and you’ll be set for a few basic artifacts. You can then add and remove the items you do not need.

The --manifest parameter has been around for a few weeks now in the current GA version of the CLI.

Faster list of authorized orgs with force:auth:list

Since the launch of the CLI, the command force:org:list has reported all the orgs you have connected to your local environment, and their current states (for instance: Is the authorization active or not? Is the scratch org active? When does it expire?). This comprehensive listing of orgs requires time as each authorization is tested and scratch org information retrieved from your dev hub orgs.

There was a quick and dirty way to get a list of orgs with force:alias:list but that relied on you having actually created an alias (which is not automatic) and didn’t contain any information about the authorization endpoint or OAuth token.

Now we’ve added a new command, force:auth:list , to get a quick list of locally authorized orgs, their URL endpoints, and current OAuth token without the server roundtrip. Just take heed of three little things: First of all, to get the OAuth token, be sure to use the --json parameter. Secondly, the alias name does not display, so you’ll have to know the authorized username of the org. Finally, scratch org status is not stored locally, so force:auth:list will display every single scratch org you’ve ever used in history. To get a more manageable list of scratch orgs, be sure to run force:org:list --clean on a regular basis to clear out the cruft left over from expired scratch orgs.

Here’s my list of scratch orgs before running --clean.

Once I cleaned up all my old scratch orgs, my list was much more manageable (although I’ll miss all the inspirational domain prefixes like “agility-power”).

And just to show it, when you run force:auth:list --json each org output object in the JSON array will have an accessToken property containing the OAuth access token.

The force:auth:list command is already available in your up-to-date CLI without upgrading to pre-release.

More control on package install

Our final Salesforce CLI tidbits include some new features that have been added to the force:package:install command.

First is the —apexcompile feature. This feature allows you to decide how the Apex code in your org will compile when you install an unlocked package. Normally a package installation will trigger a compile of all Apex in the destination org. However, if you use --apexcompile package only the Apex in the package itself will be compiled.

The other is the --upgradetype delete parameter setting. This setting deletes no longer used code or metadata from your package. Previously, you could go as far as deprecating features, but actual deletion of a code artifact during an upgrade was not possible. Score one for the advocates for clean code!

Note: This setting does not operate on custom objects or fields. Also, attempts to delete something still referenced by another piece of metadata or code will fail.

Keeping up with the CLI

To wrap up, I want to reiterate for all you CLI lovers out there: the command line ships new features weekly. That’s right, every week there are a few new goodies that will arrive. All you need to do is run sfdx update. This updates both the sfdx command line engine and the Salesforce CLI plugin (the thing that bundles all the force commands).

Due to the weekly release cycle, if you want to keep up with these incremental changes, be sure to follow the official Salesforce CLI release notes. It will include all the details you need to know about updates and fixes that are pushed out between our major seasonal releases.