You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
With the new SFDX: Rename Component, we are not yet providing support for destructive changes. This can provide a strange user experience when they've Renamed the component, and no longer have access to the old metadata, but it still exists in the org. To delete the component you typically have to run SFDX: Delete from Project and Org, but after renaming the component you no longer have access to that old component.
Describe the solution you'd like
Option 1 - (Easier) Duplicate the component to create one with the old name, and keep the old component for the user to delete.
Option 2 - (Preferred) Create a more guided deletion experience where we don't let them rename until they've updated old references, and then perform destructive changes on behalf of the user.
Option 3 - (Less Preferred) Create a destructiveChanges.xml for the user so they can delete the old component once they're done?
Additional context
Example of a confusing workflow:
Rename component using the new command
Deploy new component
Navigate to Org Browser and refresh LWCs
See that the old component is still available, and can be retrieved (and then deleted this way as well, but what a roundabout way to get there)
This discussion was converted from issue #4054 on August 30, 2024 19:54.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Is your feature request related to a problem? Please describe.
With the new
SFDX: Rename Component
, we are not yet providing support for destructive changes. This can provide a strange user experience when they've Renamed the component, and no longer have access to the old metadata, but it still exists in the org. To delete the component you typically have to runSFDX: Delete from Project and Org
, but after renaming the component you no longer have access to that old component.Describe the solution you'd like
Option 1 - (Easier) Duplicate the component to create one with the old name, and keep the old component for the user to delete.
Option 2 - (Preferred) Create a more guided deletion experience where we don't let them rename until they've updated old references, and then perform destructive changes on behalf of the user.
Option 3 - (Less Preferred) Create a destructiveChanges.xml for the user so they can delete the old component once they're done?
Additional context
Example of a confusing workflow:
Beta Was this translation helpful? Give feedback.
All reactions