Workflow for Second-Generation Managed Packages

You can create and install a second-generation managed package (managed 2GP) directly from the command line.

Review and complete the steps in Before You Create Second-Generation Managed Packages before starting this workflow.

The basic managed 2GP workflow includes these steps. See specific topics for details about each step.

  1. Create a DX project.
    sf project generate --output-dir expense-manager-workspace --name expenser-app
  2. Authorize the Dev Hub org.
    sf org login web --set-default-dev-hub

    When you perform this step, include the ---set-default-dev-hub option. You can then omit the Dev Hub username when running subsequent Salesforce CLI commands.

    If you define an alias for each org you work with, it’s easy to switch between different orgs from the command line. You can authorize different orgs as you iterate through the package development cycle.

    Tip

  3. Create a scratch org and develop the app you want to package. You can use VS Code and the Setup UI in the scratch org to build and retrieve the pieces you want to include in your package. Navigate to the expenser-app directory, and then run this command.
    sf org create scratch --definition-file config/project-scratch-def.json
  4. Verify that all package components are in the project directory where you want to create a package. If you’re trying out the exact steps and commands in this workflow, you must add at least one piece of metadata before you continue to the next step.
  5. In the sfdx-project.json file, specify a namespace using the namespace attribute. For example: “namespace”: “exp-mgr”

    If you specified a namespace when you created a Salesforce DX project in step one, you can skip this step. Before adding a namespace, make sure that you’ve linked the namespace to your Dev Hub org.

  6. From the Salesforce DX project directory, create the package.
    sf package create --name "Expense Manager" --path force-app --package-type Managed
    Your new managed 2GP package has the namespace you specified in the sfdx-project.json file.

    After you create a package, you can’t change or add a namespace, or change the Dev Hub the package is associated with.

    Important

  7. Review your sfdx-project.json file. The CLI automatically updates the project file to include the package directory and creates an alias based on the package name.
    {
       "packageDirectories": [
          {
             "path": "force-app",
             "default": true,
             "package": "Expense Manager",
             "versionName": "ver 0.1",
             "versionNumber": "0.1.0.NEXT"
          }
       ],
       "namespace": "exp-mgr",
       "sfdcLoginUrl": "https://login.salesforce.com",
       "sourceApiVersion": "51.0",
       "packageAliases": {
          "Expense Manager": "0Hoxxx"
       }
    }

    Notice the placeholder values for versionName and versionNumber. You can update these values, or indicate base packages that this package depends on. Your project file displays the namespace you created.

    Specify the features and org settings required for the metadata in your package using an external .json file, such as the scratch org definition file. You can specify using the --definition-file flag with the sf package version create command, or list the definition file in your sfdx-project.json file. See: Project Configuration File for a Second-Generation Managed Package

  8. Create a package version. This example assumes the package metadata is in the force-app directory.
    sf package version create --package "Expense Manager" --code-coverage --installation-key test1234 --wait 10
  9. Install and test the package version in a scratch org. Use a different scratch org from the one you used in step three.
    sf package install --package "Expense Manager@0.1.0-1" --target-org MyTestOrg1 --installation-key test1234 --wait 10 --publish-wait 10
  10. After the package is installed, open the scratch org to view the package.
    sf org open --target-org MyTestOrg1

Package versions are beta until you promote them to a managed-released state. See: Release a Second-Generation Managed Package.