Farewell Package.xml…you will not be missed

Salesforce’s Spring 21 release has brought about a lot of big changes. Some I am not so thrilled with, but one has so far been nice to see.

Sandbox Source Tracking went GA with this release. This is meant to help us poor developers keep track of all metadata changes between our local VS Code source repositories and the actual Sandbox/Scratch orgs.

In a nutshell, it appears to me that the dreaded package.xml file will be going away, eventually. This file has caused far too many problems (especially for teams of developers). Instead of having to manually track all metadata data changes, Salesforce will automatically keep those changes synchronized between your local development workspace and the org. THANK YOU Salesforce!

Now before you get too excited, this is NOT going to be an easy transition. For starters, a force:source:pull will not get you all the metadata from an org. I experienced problems just trying to do a simple demo with a scratch org this past weekend, using brand new code.

I anticipate a lot of customers are going to experience huge problems as a result of this change. This will be especially difficult for legacy customers with huge monolith orgs that have not been untangled.

But, I do believe this step is necessary to allowing all Salesforce developers to really emerge from the 90’s and start doing serious modern web development. Before you go too far with this, you need to know what you are dealing with. Start by checking out this Developer Blog article. I am sure there will be lots more Trailhead modules/videos etc to come on this.

So, this is not some “magic pill” to solve all development/deployment problems. But, it is a good first step. Looking forward to seeing problems addressed and enhancements made.

Top 5 Tips for Working with Salesforce Extensions for Visual Studio Code

After spending quite a lot of time working with the Salesforce Extensions for Visual Studio Code and discovering many hidden gems, here is a list of my top 5 tips. Hope they help you in your development journey.

#1 – Install the Expanded Extension Pack

This VERY handy version of the regular Salesforce Extension Pack, includes not only all the core SFDX plugin’s, but all the third-party ones you might need, like Prettier, ESLint, etc.

Salesforce Expanded Extension Pack
Salesforce Expanded Extension Pack

#2 – Run Update as Often as Possible

This is perhaps the MOST important tip I will offer. Unlike the rest of Salesforce software, the SS Salesforce Extensions are updated every week. That’s right. And they are constantly adding really cool features, so if you have not run…

sfdx update

in a while, you are probably wayyyyy behind and need to do it immediately!

#3 – Use the CLI Help Feature

For all of you that depend solely on the Command Palette, you really need to start using the built-in help that is offered. Come on, the Terminal is not that scary.

Not only will you get access to some really helpful info, but you will learn a heck of a lot about the CLI in general. Start by just typing sfdx help.

Go even further down the stack, but use –help past the first level. For example, to see the help for the project create command, so the following:

sfdx force:project:create --help
Use the built-in help feature
Use the built-in help feature

#4 – Use Code Completion and Snippets

If you do a lot of work with Apex, then you definitely want to check out using the Code Completion and Code Snippets features. This can be really helpful when creating Apex classes or triggers (especially if you are like me and do not do it that often).

#5 – See all SFDX Commands

When you are first learning how to work with the extensions, it can be helpful to see a list of all the available commands. This is accomplished by entering the following command: sfdx commands

See all the SFDX commands
See all the SFDX commands