Second-Generation Managed Packaging Developer Guide
j
No Results
Search Tips:
- Please consider misspellings
- Try different search keywords
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 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.
- 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 Second-Generation Managed Packages.
- When adding components to your package, check the product documentation for that component to ensure that the product is generally available (GA). If you choose to package a non-GA component, it may have limitations and isn't guaranteed to GA. This scenario is particularly risky if the component can't be removed from a managed package.