sfdx-plugin-package-xml

sfdx plugin for generating a package.xml manifest

Usage no npm install needed!

<script type="module">
  import sfdxPluginPackageXml from 'https://cdn.skypack.dev/sfdx-plugin-package-xml';
</script>

README

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 plugin for generating a package.xml manifest

Actions Status

Installation

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

Usage

Commands

sfdx force:mdapi:listallmetadata -h
sfdx package.xml:generate -h

:warning: Note: The first command is similar to the official (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. "sfdx force:org:pull")

sfdx force:mdapi:listallmetadata -f /tmp/fileproperties.json -u acme-dev
sfdx package.xml:generate -j /tmp/fileproperties.json -f package.xml --apiversion 54.0
sfdx force:source:retrieve -x package.xml -u acme-dev

Explore Metadata in an org named acme-dev

sfdx force:mdapi:listallmetadata --names -u acme-dev
# include child Metadata such as CustomField and filter for CustomFields on Account
sfdx force:mdapi:listallmetadata --children --names -u 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:

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 sfdx force:mdapi:listallmetadata --names
  • component names (allow rules) in sfdx force:mdapi:listallmetadata --metadata
  • ignore rules in sfdx 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:
sfdx force:mdapi:listallmetadata -m "CustomObject" --managed --unlocked --names
sfdx force:mdapi:listallmetadata -m "CustomObject" --no-unmanaged --names
  1. To list CustomObjects except the ones belonging to a Managed Package OR Unlocked Package:
sfdx force:mdapi:listallmetadata -m "CustomObject" --unmanaged --names
sfdx 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.