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
sf plugins install sfdx-plugin-package-xml@beta
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
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
sf package.xml generate -j /tmp/fileproperties.json -f package.xml --api-version 54.0
sf project retrieve start --manifest 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."
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
StandardValueSet
s using a workaround because of a bug - optionally list all child Metadata Types (e.g.
CustomField
ofCustomObject
,CustomLabel
ofCustomLabels
)
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 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
andsf package.xml generate --ignore
There are some predefined filters to either filter or exclude certain metadata components:
- unmanaged
- unlocked
- managed
- managedreadonly
- managedwriteable
Examples:
- 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
- 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
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.