force:source:deploy does not honor destructiveChanges.xml

Summary

Our MDAPI project made heavy use of package.xml and destructiveChangesPost.xml (the sibling to destructiveChanges.xml)

When we converted the MDAPI format project to source format, we chose to also continue to use package.xml since it allows us to make up for the lack of source tracking in DE and EE orgs.

However, when using force:source:deploy with the -x package.xml argument, the destructiveChangesPost.xml that’s in the same directory as package.xml is not bundled into the zip that’s sent up for deployment

I’ll state the purpose of destructiveChanges.xml for completeness: It allows us to propagate deletion of components from one org to another in a reliable, repeatable fashion. ex. removing a custom field, renaming a field, deleting a VF page, etc.

Without support for an explicitly maintained destructiveChanges.xml via the CLI, it’s not true that the CLI is now a replacement for the Ant migration tool

Steps To Reproduce:

1. Convert a MDAPI project to Source format
2. Create a VF page in your org named VenueMigrator (whatever) using Dev Console
3. Define a package.xml in a directory with the following content

<Package xmlns="http://soap.sforce.com/2006/04/metadata">
	<types>
		<members>*</members>
		<name>ApexPage</name>
	</types>
	<version>46.0</version>
</Package>

1. Define a destructiveChanges.xml in the same directory with the following content

<Package xmlns="http://soap.sforce.com/2006/04/metadata">
	<types>
		<members>VenueMigrator</members>
		<name>ApexPage</name>
	</types>
	<version>46.0</version>
</Package>

1. Execute a force:source:deploy -x package.xml
2. Expected: The VenueMigrator page should be deleted
3. Actual: The VenueMigrator page is not deleted

Additional information

SFDX CLI Version(to find the version of the CLI engine run sfdx --version): sfdx-cli/7.25.3-16d54c01ee win32-x64 node-v10.15.3

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core) @oclif/plugin-commands 1.2.3 (core) @oclif/plugin-help 2.2.1 (core) @oclif/plugin-not-found 1.2.3 (core) @oclif/plugin-plugins 1.7.8 (core) @oclif/plugin-update 1.3.9 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-trust 3.0.5 (core) analytics 1.2.1 (core) etcopydata 0.4.4 generator 1.1.1 (core) salesforcedx 46.15.3 (core) ├─ force-language-services 46.22.0 (core) └─ salesforce-alm 46.20.0 (core)

sfdx-cli 7.25.3 (core)

OS and version: Windows 10 Pro

[gdman]

@clairebianchi - even if the work is being managed outside of Github, could these issues be left open until they are fixed? From an external point of view it’s difficult to know what has and hasn’t been fixed.

Could there be a simple implementation (even if it’s only in the interim) to do something like: force:source:deploy [existing args] [--destructivepre destructiveChangesPre.xml] [--destructivepost destructiveChangesPost.xml]

If one or more of the destructive args are populated copy the file(s) into the temp directory that gets pushed to the Metadata API.

I understand that there are loads of things that need to be done and everything has to be prioritised but it’s small things like this that block us from adopting source functionality.

[gdman]

Whilst the ticket shouldn’t have been closed originally (IMO), the functionality does exist now. You can use the following args: --predestructivechanges <filepath> --postdestructivechanges <filepath>