Many of our Development blog posts spring from troubleshooting issues we uncover as we solve challenges for our customers. Here’s one…

Setting the Stage

Let’s assume you have an org where you have created 50 Lightning Components, and named them as follows:


The Problem

You  tested and everything is working, but business decides they want to change the name of all these Lightning Components.

If you have been in Salesforce development, renaming classes or triggers or Visualforce, you are already aware of metadata API, and ANT or JSForce. You immediately download all the Apex classes and triggers, rename them manually, change the names in package.xml, deploy and then probably use destructive xml to destroy old files. Doesn’t sound fun, right? However, the structure of the files is manageable (every class, page or trigger is just one file) and hence no big deal. If I’m doing such tasks, I’ll tune into music or a podcast to kill some boredom.

Now, when it comes to Lightning Components, we have many files in a bundle. Let’s say each of our bundles has 5 files. For 50 Lightning Components we have 5*50=250 files. This means if we took 10 minutes to rename 50 class files, we’d need 50 minutes to rename Lightning Components. (You might be thinking more music is the solution!)

There is an Idea here. Feel free to vote for it or leave it depending on how you feel after reading this post further. If you have a tech savvy friend, their solution might be to write some Python or Java or Node to help you with this issue. Or…

How About a Native Solution?

Reading through the docs, I discovered a SOAP API that not only carries the definition of the bundles but I can modify them. Read about these here and here.

Let’s try to use the Developer Console Query Editor and update the names of the Lightning Components to see what happens. Run this query in the Query Editor.

Select Id, DeveloperName from AuraDefinitionBundle

Let’s change the name of the TestLighntingBaseComponents to CodeScienceLightningBaseComponents and hit save.

Boom. Problem Solved

There you go. That’s it. It will automatically take care of renaming Javascript helpers, controllers and other files, and you don’t have to worry about renaming the folders manually. To do this in bulk, we can use Dataloader to extract data from this object, change the name, and upload it back.

If you have Lightning Components already moved to higher environments, you might want to create a destructive XML to get rid of old ones. Again, an extract from this table will help you.

Final Thoughts and a Word of Caution

If you have dynamically referenced names of components in code, then you will need to replace them in code. If it’s part of the markup, then the compiler won’t allow you to save and replace them easily. However, if it’s referenced in Javascript Helper or Controller, you will need to replace them.

Whenever you change something, always test. Even better? Write Selenium tests and hopefully – in coming releases (Safe Harbor) – we’ll see unit tests for Lightning Components like Apex.

Want to learn how CodeScience can help your business thrive on the AppExchange? Visit today.