https://github.com/mcarvin8/sf-package-combiner
Combine multiple Salesforce manifests (package.xml) into 1 file for deployments.
https://github.com/mcarvin8/sf-package-combiner
continuous-deployment deployment manifest salesforce
Last synced: 20 days ago
JSON representation
Combine multiple Salesforce manifests (package.xml) into 1 file for deployments.
- Host: GitHub
- URL: https://github.com/mcarvin8/sf-package-combiner
- Owner: mcarvin8
- License: mit
- Created: 2024-11-08T03:26:24.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2026-05-26T17:18:16.000Z (about 1 month ago)
- Last Synced: 2026-05-26T19:25:06.829Z (about 1 month ago)
- Language: TypeScript
- Homepage:
- Size: 1.59 MB
- Stars: 2
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE.md
Awesome Lists containing this project
README
# sf-package-combiner
[](https://www.npmjs.com/package/sf-package-combiner)
[](https://npmjs.org/package/sf-package-combiner)
[](https://raw.githubusercontent.com/mcarvin8/sf-package-combiner/refs/heads/main/LICENSE.md)
[](https://qlty.sh/gh/mcarvin8/projects/sf-package-combiner)
[](https://codecov.io/gh/mcarvin8/sf-package-combiner)
[](https://dashboard.stryker-mutator.io/reports/github.com/mcarvin8/sf-package-combiner/main)
`sf-package-combiner` merges multiple `package.xml` manifests into one. Use it in CI/CD pipelines to combine sfdx-git-delta output, manual lists, or other tool-generated manifests before a single `sf project deploy start`.
Table of Contents
- [Quick start](#quick-start)
- [Command reference](#command-reference)
- [`sf sfpc combine`](#sf-sfpc-combine)
- [How it works](#how-it-works)
- [Example](#example)
- [Invalid package.xml files](#invalid-packagexml-files)
- [Requirements](#requirements)
- [Issues](#issues)
- [License](#license)
---
## Quick start
```bash
# Install
sf plugins install sf-package-combiner@latest
# Combine 2 manifests into 1
sf sfpc combine -f pack1.xml -f pack2.xml -c package.xml
```
Mix files and directories: use `-f` for specific files, `-d` for directories containing `package.xml` files.
---
## Command reference
### `sf sfpc combine`
Combine Salesforce manifest files into one `package.xml`.
```
USAGE
$ sf sfpc combine [-f ] [-d ] [-c ] [-v ] [-n] [--json]
FLAGS
-f, --package-file= Path to a package.xml file. Can be repeated.
-d, --directory= Path to a directory containing package.xml files. Can be repeated.
-c, --combined-package= Path for the output file. Default: package.xml
-v, --api-version= API version for the combined package (e.g. 62.0).
-n, --no-api-version Omit the element in the output.
GLOBAL FLAGS
--json Output as JSON.
```
**Examples**
```bash
# Two files → package.xml (overwrites the input)
sf sfpc combine -f package.xml -f pack2.xml -c package.xml
# Files + directory
sf sfpc combine -f pack1.xml -f pack2.xml -d "test/sample_dir" -c package.xml
# Pin API version
sf sfpc combine -f pack1.xml -f pack2.xml -v "62.0" -c package.xml
# No version in output
sf sfpc combine -f pack1.xml -f pack2.xml -n -c package.xml
```
---
## How it works
- **Metadata types** — `` values are normalized via Salesforce's metadata registry (correct casing, deduped).
- **Type order** — `CustomObject` is always listed before all other types; remaining types sort alphabetically. This avoids deployment failures when `CustomObject` and its children appear in the same manifest (see [scolladon/sfdx-git-delta#76](https://github.com/scolladon/sfdx-git-delta/pull/76)).
- **Members** — `` values keep their original case (Salesforce API names are case-sensitive).
- **API version** — Highest `` from all input manifests is used. Override with `-v`, or omit entirely with `-n`.
---
## Example
**Input: `package1.xml`**
```xml
MyApexClass
ApexClass
60.0
```
**Input: `package2.xml`**
```xml
MyTrigger
ApexTrigger
62.0
```
**Command**
```bash
sf sfpc combine -f "package1.xml" -f "package2.xml" -c "package.xml"
```
**Output: `package.xml`**
```xml
MyApexClass
ApexClass
MyTrigger
ApexTrigger
62.0
```
Highest input version (`62.0`) is used.
---
## Invalid package.xml files
Files that don't match the expected manifest structure or have no `` are skipped with a warning. The underlying error from `@salesforce/source-deploy-retrieve` (SDR) is appended:
```
Warning: Invalid or empty package.xml: .\test\samples\invalid2.xml. [SDR] Missing metadata type definition in registry: CustomFields
```
> **Note:** A missing metadata type definition can also occur if the metadata type is newer than the SDR version bundled with this plugin. Dependabot checks for SDR updates weekly and auto-merges updates when the metadata registry changes.
If every input is invalid or empty, the output will have no ``. Guard against deploying an empty package:
```bash
sf sfpc combine -f "package/package.xml" -f "package.xml" -c "package.xml"
if grep -q '' ./package.xml; then
echo "---- Deploying added and modified metadata ----"
sf project deploy start -x package.xml
else
echo "---- No changes to deploy ----"
fi
```
---
## Requirements
- [Salesforce `sf` CLI](https://developer.salesforce.com/tools/sf)
- Node.js **20.x or later**
---
## Issues
Bugs or feature requests? Submit an [issue](https://github.com/mcarvin8/sf-package-combiner/issues).
---
## License
[MIT](LICENSE.md)