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
Partner Licensing Platform (Developer Preview)
Unlocked Packages
What’s a Package
Package-Based Development Model
Before You Create Unlocked Packages
Know Your Orgs
Create Org-Dependent Unlocked Packages
Workflow for Unlocked Packages
Configure Packages
Project Configuration File for Packages
Unlocked Packaging Keywords
Package Installation Key
Extract Dependency Information from Unlocked Packages
Understanding Namespaces
Share Release Notes and Post-Install Instructions
Specify Unpackaged Metadata or Apex Access for Apex Tests (Unlocked Packages)
Best Practices for Unlocked Packages
Package IDs and Aliases for Unlocked Packages
Frequently Used Packaging Operations
How We Handle Profile Settings in Unlocked Packages
Create a Package
Push a Package Upgrade
Install a Package
Migrate Deprecated Metadata from Unlocked Packages
Uninstall a Package
Transfer an Unlocked Package to a Different Dev Hub (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

Best Practices for Unlocked Packages

We suggest that you follow these best practices when working with unlocked packages.
  • We recommend that you work with only one Dev Hub, and enable Dev Hub in a production 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.
  • Use care in deciding how to utilize namespaces. For most customers, we recommend working with no namespace or a single namespace to avoid unnecessary complexity in managing components. If you’re test-driving unlocked packages, use a test namespace.

    Use real namespaces only when you’re ready to embark on a development path headed for release in a production org.

    You can’t install a no-namespace, unlocked package into any org with a namespace (for example, a scratch org with a namespace).

    Note

  • 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 for Unlocked Packages.