As their name suggests, extension packages extend or add to the functionality delivered by the existing packages they are based on, though they cannot change the base package contents. They can extend one or more base packages, and you can even have several layers of extension packages, though you may want to keep an eye on how extensively you use this feature, as managing inter-package dependency can get quite complex, especially during development and deployment when using features such as Push Upgrade.
Extension packages are created in much the same way as the process you've just completed, except that you must define the dependent package in the sfdx-project.json file (shown as follows) and ensure the Scratch Org has those base packages installed in it before use. The following is an example sfdx-project.json file showing a package dependency for a new extension package that is currently in development:
{
"packageDirectories": [
{
"path": "force-app",
"package": "FormulaForce - Advanced Analytics Addon",
"default": true,
"dependencies": [
{
"package": "FormulaForce [email protected]"
}
]
}
],
"namespace": "bookns1",
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "45.0",
"packageAliases": {
"FormulaForce [email protected]": "04t6A012003AB3GQAU"
}
}
The project containing the preceding example configuration only contains the extension package components, since there is only one packageDirectories entry. In this case, the base package is developed in a separate project. However, as noted earlier, you can have multiple packages within a single SFDX project. This does have the benefit of being able to work on both base and extension packages together in one scratch org. However, it requires more careful management of the default package directory setting when performing synchronization operations. Personally, I find that having separate projects enforces a better mindset when managing how packages are coupled.
As the code contained within extension packages makes reference to other Custom Objects, Custom Fields, Apex code, and so on that are present in base packages, the platform tracks these dependencies and the version of the base package present at the time the reference was made. When an extension package is installed, this dependency information ensures that the subscriber (customer) org has the correct version (minimum) of the base packages installed before permitting the installation of the extension package to complete.
The preceding sections have described the package creation process, including the ability to create other extension packages to allow you to deploy parts of your application that are applicable to only a subset of your customers, for example, for a given market. The following sections introduce concepts that require more understanding before you release your package to your target customers. Some of these things cannot be reverted.