4

I realize the command is still in beta, but I am unable to delete a custom field using the force:source:delete command.

I have tried force:source:delete -m CustomField:myObject__c.myField__c, which results in the error ERROR: Cannot read property 'split' of undefined

And I have tried force:source:delete -p .\objects\myObject__c\fields\myField__c.field-meta.xml which returns a No results found message.

Needless to say, in neither case does the field get deleted (note that I have deliberately omitted the -u parameter in the above examples for simplicity).

Finally, as an aside, the -p parameter I find problematic because if you have deleted the field in your scratch org the corresponding metadata file is also deleted, which means that there is no metadata file to point to when attempting to delete from a sandbox. I suspect the -m parameter also implicitly assumes that a metadata file exists (which it does in case anyone is thinking I have removed it - in fact, the same error results regardless). What makes more sense (at least to me) is to have say a -x destructiveChanges.xml type parameter.

1
5

I believe this is a bug in the CLI plugin for windows that you might want to report to salesforce CLI team by creating a case or via twitter.

However there is a simple workaround for it using mdapi commands that will work .

Follow the below steps

1.Create a directory named destroy .

2.Create a package.xml file as below in the above directory .Name the the file package.xml

<?xml version="1.0" encoding="UTF-8"?>
 <Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>44.0</version>
 </Package>

3.Create another file named as destructiveChanges.xml as shown below

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
   <types>
    <members>ObjectName__c.Field_Name__c</members>
    <name>CustomField</name>
   </types>
  <version>44.0</version>
</Package>

4.Run the command as below

sfdx force:mdapi:deploy -d destroy -u <alias> -w -1
3
  • That works, and aligns more with my preference for maintaining a destructiveChanges.xml manifest anyways. Thanks for all your help. – raccoon.i Dec 20 '18 at 20:58
  • You may want to mark answered so helps communication – Mohith Shrivastava Dec 20 '18 at 20:58
  • It is a pity that it still doesn't work. I didn't plan to maintain a destructiveChanges.xml but I am forced to – Patlatus Jan 11 at 9:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.