5

I am working in a scratch org, developed the package. Everything is working fine.

I created the package.

Then when I go to create the package version it always fails on Unknown types for the dependencies....

in the sfdx-project.json I have:

{
"packageDirectories": [
    {
        "path": "force-app",
        "default": true,
        "package": "Package Name",
        "versionName": "ver 0.1",
        "versionNumber": "0.1.0.NEXT"
    }
],
"namespace": "",
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "43.0",
"dependencies": [
    {
        "package": "Namespace@1.20" // also tried the package name@ver as listed in the installed packages of the org
        //also tried this and it gets the same error
        "subscriberPackageVersionId" : "04t......"
    },
    {
        "package": "package alias",
        "versionNumber": "0.1.0.LATEST" //also tried removing this and using alias@version and 04t id in the package field
    }
],
"packageAliases": {
    "Package Alias": "0Hoxxxx"
}

}

Note I have replaced actual names with aliases.

The CLI I am using is:

sfdx force:package:version:create --package "Package Name" 
     --installationkeybypass -w 10

The First dependency is a 1st gen managed package.

The Second dependency is a 2GP (Unlocked no namespace) in the Dev Hub org. I have tried a field of "subscriberPackageVersionId" with the 04t Id, the 04t Id with the current field, and various other combinations.

The DevHub org has all the required packages installed in case that matters

Any ideas on how to properly state the dependencies to get the version created?

Note Deploying the classes directly to the production org (also dev hub org) works just fine.

According to the docs: it says "To specify dependencies for 2GP outside of the Dev Hub and for first-generation packages within or outside of the current Dev Hub, use......."

When attempting to create a package version I get the following first error:

Invalid type: ns__XXXXX__c Class Name: DML requires SObject or SObject list type: ns__XXXXX__c <- this is the SObject from the 1GP

(Tests are all good and passing in the scratch org in which I am working.)

The rest of the errors are cascading due to the first error.

ANSWER The table located HERE did not make it clear which parameter was a child or top level. Based on the selected answer it was apparent I had the dependencies object in the wrong spot in the JSON file.

0

1 Answer 1

6
+250

Perhaps I'm being really dumb here, but can't you get the 04t id for the package by reading it off the installation URL? e.g. if I try to install Lightning Flow Sample Pack from AppExchange, I end up at:

lightning.force.com/packagingSetupUI/ipLanding.app?apvId=04t1I000003coh8QAA&src=U

From which I can just read the 04t. I've successfully built 2GP packages that depend on my own 1st generation packages with just

        "dependencies": [
            {
                "subscriberPackageVersionId": "04t..."
            }
        ],

So, hopefully, you can do something like that.

Updates

Some updates from our discussion in comments:

If you don't know the installation URL, you can obtain the 04t key by running:

force:package:installed:list

on the scratch org. In Eric's case, adding the package key to his sfdx-project.json still resulting in a failure during package building.

For reference, here's the whole sfdx-project.json from a 2GP package of mine that depends on managed 1GP packages:

{
    "packageDirectories": [
        {
            "path": "force-app",
            "package": "My Package",
            "versionName": "ver 0.6",
            "versionNumber": "0.6.0.NEXT",
            "default": true,
            "dependencies": [
                {
                    "subscriberPackageVersionId": "04t1..."
                },
                {
                    "subscriberPackageVersionId": "04t5..."
                }
            ],
            "ancestorVersion": "0.5.0.1"
        }
    ],
    "namespace": "nebc",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "43.0",
    "packageAliases": {
        "My Package": "0Ho...",
        "My Package@0.1.0-1": "04t...rQAC",
        "My Package@0.1.0-2": "04t...1QAC",
        "My Package@0.2.0-1": "04t...6QAC",
        "My Package@0.4.0-1": "04t...QQAS",
        "My Package@0.5.0-1": "04t...VQAS",
        "My Package@0.6.0-1": "04t...bQAC"
    }
}
2
  • if a subscriberPackageVersionId gets updated in the subscribers org, this shouldn't cause an issue correct? Nov 3, 2020 at 15:07
  • You'd probably be best advised to update the id in your project file to match production each time you work on the 2GP package. Just to make sure you're as close to the real environment as possible. But I don't think it would just break if you didn't
    – Aidan
    Nov 4, 2020 at 9:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .