Salesforce DX Developer Guide

How Salesforce Developer Experience Changes the Way You Work
Enable Dev Hub Features in Your Org
Project Setup
Authorization
Metadata Coverage
Scratch Orgs
Sandboxes
Track Changes Between Your Project and Org
Development
Build and Release Your App
First-Generation Managed Packages
Second-Generation Managed Packages
What’s a Package?
Comparison of 2GP and 1GP Managed Packages
Namespaces
Package IDs and Aliases
Before You Create Second-Generation Managed Packages
Workflow for Second-Generation Packages
Configure Packages
Best Practices for Second-Generation Managed Packages
Frequently Used Packaging Operations
Create a Package
Push a Package Upgrade
Install a Package
Uninstall a Package
Publishing Your App on AppExchange
Gaps Between First-Generation and Second-Generation Managed Packaging
Test and Respond to the New Order Save Behavior
Unlocked Packages
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
PDF

Newer Version Available

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

Best Practices for Second-Generation Managed Packages

We suggest that you follow these best practices when working with second-generation managed packages.
  • We recommend that you work with only one Dev Hub, and enable Dev Hub in your partner business org.
  • The Dev Hub org against which you run the force:package:create command becomes the owner of the package. If the Dev Hub org associated with a package expires or is deleted, its packages no longer work.
  • Include the --tag option when you use the package:version:create and package:version:update commands. This option helps you keep your version control system tags in sync with specific package versions.
  • Create user-friendly aliases for packaging IDs, and include those aliases in your Salesforce DX project file and when running CLI packaging commands. See: Package IDs and Aliases.