Salesforce DX Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
How Salesforce Developer Experience (DX) Tooling Changes the Way You Work
Provide Developers Access to Salesforce DX Tools
Project Setup
Authorization
Metadata Coverage
Scratch Orgs
Sandboxes
Track Changes Between Your Project and Org
Work with Data
Development
Build and Release Your App
Unlocked Packages
What’s an Unlocked Package?
Package-Based Development Model
Before You Create Unlocked Packages
Know Your Orgs
Create Org-Dependent Unlocked Packages
Workflow for Unlocked Packages
Configure Unlocked Packages
Project Configuration File for Unlocked 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 Unlocked Packaging Operations
How We Handle Profile Settings in Unlocked Packages
Develop Unlocked Packages
Push a Package Upgrade for Unlocked Packages
Install an Unlocked Package
Migrate Deprecated Metadata from Unlocked Packages
Uninstall an Unlocked Package
Transfer an Unlocked Package to a Different Dev Hub
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
PDF

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 sf 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 sf package version create and sf 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.