Automatically install Second-Generation Packages dependencies with a custom sfdx plugin
If you’ve started using Salesforce DX, it’s likely you’ve already seen this picture of happy Trailhead characters moving metadata from the so-called “Happy soup” to separate projects:
In an older blog post, I wrote about our first steps with DX and Unlocked Packages. We started small with a new project that had no dependency with the existing org’s metadata.
At some point however, having more complex projects required to split metadata in separate projects and packages.
I’m not going to talk about the best strategy to split your org in separate projects, but if you’re interested (and I’m sure you are), you can have a look to the great blog post serie Working with Modular Development and Unlocked Packages on Salesforce Developer blog, or John Daniel & Dileep Burki’s talk at TDX18, Architecting Unlocked Packages in your Salesforce Org.
What is a Package
Before talking about dependencies, it’s important to understand what exactly is a package and what makes it unique.
A package has 2 parts:
- a Package Id (starting by 0Ho)
- a Package Version Id (starting by 04t)
You first create your Package, and then create versions of it that you will install and upgrade over time. It’s almost the same thing as what you get with an App Exchange package.
For instance you could create a package for your Service Cloud project, and then deploy several versions of it. So you’ll have:
- Your package “ServiceCloudProject”, Id 0Hoxxxxxxxxxxxx (would never change)
- Your package version ServiceCloudProject v1.0, Id 04tyyyyyyyyyyyy
- Your package version ServiceCloudProject v1.1, Id 04tzzzzzzzzzzzz
Additionally, depending on your branching model, you could have one version per branch, so for instance:
- a ServiceCloudProject v1.1 for the dev branch
- a ServiceCloudProject v1.1 for the release branch
Both would have a different Package Version (04t) id (but you can definitely build one version and deploy it everywhere without using the branch tag).
So to sum up, you can target a specific and unique package version with:
- Its Package Version Id (04t)
- Its Package Id (0ho) + its Version Number + its Branch
Packages Dependency
Let’s take a fictional project that would be separated in 4 Packages like this:
Let’s say you need to work on Project B, you’ll have to install the Base package first. To work on Project C, you’ll need to install both the Base package and Project B package. So how does it work ?
Specifying dependencies
Dependencies are listed in your project definition file (sfdx-project.json). For Project C, you’ll have something like this…
