Second-Generation Managed Packaging Developer Guide

Second-Generation Managed Packages
What’s a Second-Generation Managed Package?
Before You Create Second-Generation Managed Packages
Workflow for Second-Generation Managed Packages
Components Available in Managed Packages
Behavior of Specific Metadata in Second-Generation Managed Packages
Develop Second-Generation Managed Packages
Install and Uninstall Second-Generation Managed Packages
Prepare to Distribute Your Second-Generation Managed Package
Push a Package Upgrade for Second-Generation Managed Packages
Advanced Features for Second-Generation Managed Packages
Package Ancestors for Second-Generation Managed Packages
Patch Versions for Second-Generation Managed Packages
Create Dependencies Between Second-Generation Managed Packages
Advanced Project Configuration Parameters for Second-Generation Managed Packages
Skip Validation to Quickly Iterate Second-Generation Managed Package Development
Second-Generation Managed Packaging Keywords
Target a Specific Release for Your Second-Generation Managed Packages During Salesforce Release Transitions
Use Branches in Second-Generation Managed Packaging
Specify Unpackaged Metadata or Apex Access for Package Version Creation Tests for Second-Generation Managed Packages
Package IDs and Aliases for Second-Generation Managed Packages
Avoid Namespace Collisions in Second-Generation Managed Packages
Remove Metadata Components from Second-Generation Managed Packages
Delete a Second-Generation Managed Package or Package Version
Frequently Used Packaging Operations for Second-Generation Managed Packages
Transfer a Second-Generation Managed Package to a Different Dev Hub
Best Practices for Second-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in Second-Generation Managed Packages
Get Started with AppExchange App Analytics
Gaps Between First-Generation and Second-Generation Managed Packaging
PDF

Newer Version Available

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

Advanced Project Configuration Parameters for Second-Generation Managed Packages

As your managed 2GP package development becomes more complex, consider including these optional parameters in your sfdx-project.json file.
Name Details
apexTestAccess Required? No

Default if Not Specified: None

Assign permission sets and permission set licenses to the user in context when your Apex tests run at package version creation.
1"apexTestAccess": {
2               "permissionSets": [
3                   "Permission_Set_1",
4                   "Permission_Set_2"
5               ],
6               "permissionSetLicenses": [
7                   "SalesConsoleUser"
8               ]
9           }

See Specify Unpackaged Metadata or Apex Access for Package Version Creation Tests for Second-Generation Managed Packages
branch Required? No

Default if Not Specified: None

If your package has an associated branch, but your package dependency is associated with a different branch, use this format. 
1"dependencies": [
2    {
3    "package": "pkgB",
4    "versionNumber": "1.3.0.LATEST",
5    "branch": "featureC"
6   }
7]

If your package has an associated branch, but your package dependency doesn’t have an associated branch, use this format.

1"dependencies": [
2    {
3    "package": "pkgB",
4    "versionNumber": "1.3.0.LATEST",
5    "branch": ""
6    }
7]

See Use Branches in Second-Generation Managed Packaging
dependencies Required? No

Default if Not Specified: None

Specify the dependencies on other packages.
To specify dependencies for managed packages within the same Dev Hub, use either the package version alias or a combination of the package name and the version number.
1"dependencies": [ 
2   {
3      "package": "MyPackageName@0.1.0.1"
4   }
5]
1"dependencies": [ 
2   {
3      "package": "MyPackageName",
4      "versionNumber": "0.1.0.LATEST"
5   }
6]
To specify dependencies for managed packages outside of the Dev Hub use: 
1"dependencies": [ 
2   {
3      "package": "OtherOrgPackage@1.2.0"
4   }
5]

You can use the LATEST keyword for the version number to set the dependency.

Note

To denote dependencies with package IDs instead of package aliases, use:
  • The 0Ho ID if you specify the package ID along with the version number
  • The 04t ID if you specify only the package version ID
If the package has more than one dependency, provide a comma-separated list of packages in the order of installation. For example, if a package depends on the package Expense Manager - Util, which in turn depends on the package External Apex Library, the package dependencies are: 
1"dependencies": [
2   {
3      "package" : "External Apex Library - 1.0.0.4"
4
5         },
6   {
7      "package": "Expense Manager - Util",
8      "versionNumber": "4.7.0.LATEST"
9
10   }
11]
postInstallScript Required? No

Default if Not Specified: None

An Apex script that runs automatically in the subscriber org after the managed package is installed or upgraded.
postInstallURL Required? No

Default if Not Specified: None

A URL to post-install instructions for subscribers.
releaseNotesUrl Required? No

Default if Not Specified: None

A URL to release notes.
unpackagedMetadata Required? No

Default if Not Specified: None

See Specify Unpackaged Metadata or Apex Access for Package Version Creation Tests for Second-Generation Managed Packages.
uninstallScript Required? No

Default if Not Specified: None

An Apex script to run automatically in the subscriber org before the managed package is uninstalled.