Extending a picklist with additional values 2GP

Question

I'm creating a 2 GP package packageB which depends on several 1 GP packages. In packageB, I'd like to extend a picklist from packageA, one of the managed packages, with additional values. I tried doing it by adding a file packageA__packageAField__c.field-meta.xml under the folder src/main/default/objects/packageA__packageAObject__c.fields in packageB's source directory, and adding the new picklist values there.

This worked in my development scratch org for packageB, as well as the test scratch org. However in the scratch org that Salesforce uses for releasing a package (and that we seem to have no visibility into), I got the following error:

"You're trying to include CustomField packageA__PackageAObject__c.packageA__packageAField__c in Package Release. This component already exists in Package null, which Package Release depends on. You can't include the same component in both packages."

How do I get this done please? Some of my test cases depend on the extended picklist values so I need them in the release org.

Not sure why packageA comes up as Package null either!

Answer 1

Individual picklist values are not packageable entities. Since you also cannot package a custom field that's owned by another managed package, there's actually no way for you to package these changes for delivery to your users.

You'll have to deliver these changes to your subscribers without using packaging, either as unpackaged metadata they install (dangerous! it overwrites their changes to picklist values), by using Metadata ETL if you're delivering with CumulusCI and MetaDeploy (disclaimer: I am on the team that builds those tools), or by documenting required setup steps for your users.

Some of my test cases depend on the extended picklist values so I need them in the release org.

You can specify additional unpackaged metadata (like your picklist customizations) to include in the build org to support Apex unit tests. I personally would feel more comfortable just removing the Apex test dependency, however. Relying on picklist values is dicey given that you cannot package changes to a parent package's values and that they're ultimately under the control of the subscriber. (Note: you also can't push-upgrade picklist values!)