SFDX Push error when metadata is moved

[rhobkirkcertinia]

Summary

SFDX Push fails when metadata is moved locally despite no content within the file changing.

We often want to move metadata around within the repo (typically Apex classes) in order to decompose the "default/classes" directory and make the repository more understandable.

The issue is that when the file is moved, the SFDX CLI mistakenly attempts to delete the file from the org, presumably due to identifying it as a new file instead. This typically causes compilation failures since the class is in use in the org and cannot be deleted.

This occurs when moving files within the same package directory.

It would be useful if the CLI could also support moving files between package directories - although I'm happy if this needs to be bumped due to the extra complexity.

Steps To Reproduce:

Repository to reproduce: ebikes-lwc

1. Clone the Ebikes LWC repo
2. Follow the README to:
   1. Create an org
   2. Push the code
3. Now refactor the code by:
   1. Creating a new directory named ebikes/classes in force-app, I.e. force-app/main/ebikes/classes/
   2. Move a class - force-app/main/default/classes/OrderController.cls + OrderController.cls-meta.xml into force-app/main/ebikes/classes/
4. Push the code - this should error as follows:

   === Component Failures [2]

   Type Name Problem
   Error OrderController This apex class is referenced elsewhere in salesforce.com. Remove the usage and try again. : Lightning Web Component Bundle "c:orderBuilder" - MODULE - orderBuilder.
   Error OrderController This apex class is referenced elsewhere in salesforce.com. Remove the usage and try again. : Lightning Web Component Bundle "c:orderBuilder" - MODULE - orderBuilder.

   ERROR running force:source:push: Push failed.

Expected result

The SFDX CLI should not attempt to delete files that have no changes besides being moved.

For moved files:

• If the content of the file has not changed, the SFDX CLI should not attempt to push anything. It should recognise that the hash of the content is the same and make no changes.
  • This is the most common scenario for us.
• If the content of the file has changed, the SFDX CLI should push the updates, but not attempt to delete the file
• If the file has been renamed, the SFDX CLI should add the file at it's new location before deleting the file from its old location

There are likely more scenarios around this, but hopefully this covers the major ones.

Actual result

SFDX CLI errors on the push.

System Information

{
  "cliVersion": "sfdx-cli/7.183.1",
  "architecture": "darwin-arm64",
  "nodeVersion": "node-v16.19.0",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 1.3.8 (core)",
    "@oclif/plugin-commands 2.2.2 (core)",
    "@oclif/plugin-help 5.1.20 (core)",
    "@oclif/plugin-not-found 2.3.13 (core)",
    "@oclif/plugin-plugins 2.1.8 (core)",
    "@oclif/plugin-search 0.0.6 (core)",
    "@oclif/plugin-update 3.0.9 (core)",
    "@oclif/plugin-version 1.1.4 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.18 (core)",
    "@oclif/plugin-which 2.2.6 (core)",
    "alias 2.1.14 (core)",
    "apex 1.3.0 (core)",
    "auth 2.3.8 (core)",
    "community 2.0.18 (core)",
    "config 1.4.22 (core)",
    "custom-metadata 2.0.5 (core)",
    "data 2.1.19 (core)",
    "generator 2.0.13 (core)",
    "info 2.3.1 (core)",
    "limits 2.2.0 (core)",
    "org 2.2.20 (core)",
    "packaging 1.12.2 (core)",
    "schema 2.2.2 (core)",
    "signups 1.2.12 (core)",
    "source 2.3.12 (core)",
    "telemetry 2.0.5 (core)",
    "templates 55.1.0 (core)",
    "trust 2.2.4 (core)",
    "user 2.1.24 (core)",
    "@salesforce/sfdx-plugin-lwc-test 1.0.1 (core)",
    "salesforce-alm 54.8.5 (core)"
  ],
  "shell": "zsh",
}

Additional Information

It's worth being aware that when a very simple project is used with no LWC referencing the class, I have seen the SFDX CLI successfully push the deletion of the moved class.
This is obviously incorrect, as the moved class still exists locally, but not in the org.

@W-7673793@

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[petter-eikeland]

We need this as well! Working with multiple package directories is a pain because of this, especially declarative changes that are made in the scratch org and then needs to be pulled down. And worse, when these changes are merged to main, everyone else pulling from main into their local branches might get the same push errors (if moving existing files).

Perhaps there could be a way of distinguishing moving (renames only including path and not filename) and no other changes with other types of changes?

[mshanemc]

I think we have a path toward handling local file renames/moves, and that's the scope of this gh issue.

"I renamed it in the org" is a much harder problem.

[petter-eikeland]

Yeah, poorly written by me. I originally added some other thoughts about creating e.g. new custom fields, pulling them down, and sorting them into different package directories. Then this push error could occur as well. But forgot to remove everything.

Fully agree with you on the scope of the issue. If this were to be solved it would resolve some headaches for us as well

[chfosli]

You also have a lot of problems with this as we try to organize metadata based on functionality in different folders (under the same project). This leads to a lot of unnecessary headaches for our developers.

[mwannamaker41]

I was just going to submit this issue.
Just a note, for something that is not referenced like a class you just created. If you move it and then push, it deletes it, but if you then immediately push again, it creates it.
Looking forward to this one. 💯

[petter-eikeland]

Any updates on this @mshanemc? We have a pretty manual workaround for this currently, by updating the forceignore file every time we need to move files between directories.

[jonny-harte]

This is definitely something that needs sorting

[mshanemc]

I'm closing this in favor of a higher-level discussion about how we want this to work. That's here. @jonny-harte @petter-eikeland @mwannamaker41 @chfosli @rhobkirkcertinia

#2682