Wildcard subscriptions in package.xml aren't removed when specific selections are made

[René Görgens]

Hi Scott,

I have no use for the wildcard subscriptions (ApexClass, ApexComponent, …) in package.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>*</members>
<name>ApexClass</name>
</types>
<types>
<members>*</members>
<name>ApexComponent</name>
</types>
<types>
<members>*</members>
<name>ApexPage</name>
</types>
<types>
<members>*</members>
<name>ApexTestSuite</name>
</types>
<types>
<members>*</members>
<name>ApexTrigger</name>
</types>
<types>
<members>*</members>
<name>AuraDefinitionBundle</name>
</types>
<types>
<members>*</members>
<name>LightningComponentBundle</name>
</types>
<types>
<members>*</members>
<name>StaticResource</name>
</types>
<version>55.0</version>
</Package>

So one of the initial steps I do on a SFDX project (besides incrementing the API version to 56 in sfdx-project.json and package.xml) is removing the above wildcards from package.xml.

[René Görgens]

Would it be possible to remove these, or make them optional during project creation? I’m afraid they’re not removed once you start making an explicit metadata selection, or are they?

[Scott Wells]

If you start manipulating the metadata subscription and, for example, deselect one or more members of those wildcarded types, yes, the wildcard should be removed. If not, that would be a bug. But the package.xml file that’s created for a source format project when Generate manifest is checked is a direct result of running sfdx force:project:create -x/--manifest and is based on the CLI’s project template for a non-source-tracked source format project. That’s not something that IC2 is creating/populating.

[René Görgens]

Thanks for the follow-up. I did a quick test in a non source controlled project against an OAuth sandbox connection:

• Retrieve Metadata: I selected 1 of each where available (1 class, 1 component, 1 page, 1 staticresource, 1 trigger – no Aura or LWC available)

  • There is only 1 staticresource, so there I would expect the wildcard subscription to remain, whereas for the others it should be replaced by the specific subscription

• Resulting source directory:

‌

• Resulting package.xml (after Reload from Disk): no change, wildcards still in place

‌

I’ll attach the log.

[René Görgens]

IDEA log file

[René Görgens]

The Metadata subscription setting is Always Update.

[Scott Wells]

What you did was a retrieval which is not the same as an explicit update to the metadata subscription. Because the subscription includes a wildcard for those metadata types, it allows individual instances of those types to be retrieved under the umbrella of that subscription. In my previous response I meant that if you go into the metadata subscription editor itself and change from a wildcard to a subset, it will be reflected in the package.xml file. What you described here is working as designed.

[Scott Wells]

This one is working as designed. IC2’s SFDX project creation is effectively a UI atop the force:project:create command including the usage of the -x/--manifest flag. When that flag is used, the project is seeded with the exact package.xml that you’re seeing as created by the CLI command. Once the project has been created--and more importantly, once it’s associated with an org via a connection since it’s only then that IC2 can enumerate the org’s actual metadata--the user can go into the metadata subscription editor and customize the desired subset of metadata for the project. A metadata retrieval does not (and should not) remove selections from the metadata subscription, though if unsubscribed metadata is retrieved and IC2 is so configured, it may add those new items to the subscription.

[Scott Wells]

Works as designed based on the behavior of the underlying force:project:create command.