sfdx-plugin-package-xml

explore metadata in an org and generate a package.xml manifest

DISCLAIMER: This is a beta version with only a few features.

Please submit issues with your feedback about errors, usability and feature requests.

sfdx/sf plugin for generating a package.xml manifest

Installation

sf plugins install sfdx-plugin-package-xml@beta

Usage

Commands

sf force mdapi listallmetadata -h
sf package.xml generate -h

⚠️ Note: The first command is similar to the official (sf force mdapi listmetadata) command.

However our command lists Metadata for ALL Metadata Types.

-force mdapi listmetadata
+force mdapi listallmetadata

Use Cases

Retrieve all Metadata from an org named acme-dev (a.k.a "Metadata Backup", a.k.a. "sf force org pull")

sf force mdapi listallmetadata -f /tmp/fileproperties.json -o acme-dev
sfdx package.xml:generate -j /tmp/fileproperties.json -f package.xml --api-version 54.0
sf force source retrieve -x package.xml -o acme-dev

Explore Metadata in an org named acme-dev

sf force mdapi listallmetadata --names -o acme-dev
# include child Metadata such as CustomField and filter for CustomFields on Account
sf force mdapi listallmetadata --children --names -o acme-dev | grep "CustomField:Account."

Concept and Implementation

Listing Metadata

General Approach:

• call describeMetadata() to retrieve a list of Metadata Types
• call listMetadata() for all Metadata Types (in chunks of max. 3 queries to adhere to the limits)
• list all folders and folder-based Metadata
• list StandardValueSets using a workaround because of a bug
• optionally list all child Metadata Types (e.g. CustomField of CustomObject, CustomLabel of CustomLabels)

Workarounds:

There are a bunch of issues with listMetadata. The following repositories provide Minimum Working Examples and Workarounds we use:

• https://github.com/mdapi-issues/listmetadata-recordtype-personaccount
• https://github.com/mdapi-issues/listmetadata-standardvalueset
• https://github.com/mdapi-issues/listmetadata-standardvaluesettranslation-type
• https://github.com/mdapi-issues/listmetadata-installed-missing-namespaceprefix

Component Names and Patterns

Component Names and Patterns have the following format: <type>:<fullName>

Examples:

CustomField:Account.Industry
CustomField:Account.*
ReportFolder:unfiled$public
Report:unfiled$public/
ApexClass:Test_*
ApexClass:*Test
ApexClass:ACME__*

For convenience you can also write CustomField instead of CustomField:*.

They are used throughout this plugin, e.g. in the

• output of sf force mdapi listallmetadata --names
• component names (allow rules) in sf force mdapi listallmetadata --metadata
• ignore rules in sf force mdapi listallmetadata --ignore and sfdx package.xml:generate --ignore

Filtering Metadata

There are some predefined filters to either filter or exclude certain metadata components:

• unmanaged
• unlocked
• managed
• managedreadonly
• managedwriteable

Examples:

1. To only list CustomObjects belonging to a Managed Package Unlocked Package:

sf force mdapi listallmetadata -m "CustomObject" --managed --unlocked --names
sf force mdapi listallmetadata -m "CustomObject" --no-unmanaged --names

2. To list CustomObjects except the ones belonging to a Managed Package OR Unlocked Package:

sf force mdapi listallmetadata -m "CustomObject" --unmanaged --names
sf force mdapi listallmetadata -m "CustomObject" --no-managed --no-unlocked --names

Package.xml

The package.xml file follows a certain format (indentation, sort order). You can discover this when using an unformatted package.xml to retrieve Metadata. The returned zip file contains a well formatted package.xml. We try to stick to this format to make working with version control systems more easy.