[SalesForce] Organize Managed Package Dependencies with Unlocked Packages

I build Managed Packages (with namespaces) for my ISV customers. I use external libraries and Open-Source frameworks like fflib or apex-domainbuilder and find dependency management gets more cumbersome the more external libs I use.

I decided to use Unlocked Packages to bundle and manage such dependencies better. Here are the sfdx-project.json files for the app and for a sample dependency.

sfdx-project.json of the Managed Package (Customer DevHub)

{
    "namespace": "NAMESPACE",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "48.0",
    "packageDirectories": [{
        "path": "force-app",
        "versionNumber": "1.1.0.NEXT",
        "package": "myManagedPackage",
        "dependencies": [
            {
            "package": "noNsUnlockedDependency@LATEST",
            }
        ]
    }],
    "packageAliases": {
        "noNsUnlockedDependency": "0Ho4A000000fxXpSAI",
        "noNsUnlockedDependency@LATEST": "04t4A000000onRXQAI",
    }
}

sfdx-project.json of the Required Library (Developer Devhub XYZ)

{
    "packageDirectories": [{
        "path": "force-app",
        "default": true,
        "package": "apex-domainbuilder",
        "versionName": "Summer '20",
        "versionNumber": "1.1.0.NEXT"
    }],
    "namespace": "",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "48.0",
    "packageAliases": {
    "noNsUnlockedDependency": "0Ho4A000000fxXpSAI",
    "noNsUnlockedDependency@1.1.0-1": "04t4A000000onRXQAI"
    }
}

As the sample dependency is created from another DevHub and/or doesnt have a namespace I can't install them.

ERROR running force:package:install: You cannot install an unlocked
package without a namespace into an org with a namespace.

  1. Why is that a requirement?
  2. Is it because the libraries use a different DevHub (the one of our company) than the Managed package (the one of the customer)?
  3. I don't want (I read here that this has some problems and limitations) or can't (because they are not my repos) add namespaces.
  4. What will I win and lose when adding namespace to the dependencies?

Best Answer

Why is that a requirement?

Because it is intended that those packages will become part of a Classic Managed Package (1GP). This restriction prevents you from accidentally creating dependencies on a package that won't become part of the namespace and Managed Package.

Is it because the libraries use a different DevHub (the one of our company) than the Managed package (the one of the customer)?

No, it's just as explained above. You can't create managed dependencies on unmanaged packages, which could cause things to break.

I don't want (I read here that this has some problems and limitations) or can't (because they are not my repos) add namespaces.

They need to be, or you can't build dependencies on them. Also, the linked FAQ is very out of date (2018). Things have changed since then. There are still some limitations, but they are very close to parity with 1GP at this point. You shouldn't be worried about the limitations too much at this point.

What will I win and lose when adding namespace to the dependencies?

You get most of the properties of 1GP (Classic Managed Packages) by adding namespaces, including upgradeability, protected components, etc. I suggest you go through the documentation and read about the latest updates. Most documents from 2018 or 2019 are outdated and the information therein should not be relied on.

Related Topic