Salesforce Extension Pack Review: Breakthrough Tool Needs Improvement
Before Visual Studio Code (VS Code) from Microsoft became the preferred integrated developer environment (IDE) for Salesforce, developers struggled with Java-based Eclipse because it was the only supported IDE. Now, in 2021 this has all changed with VS Code plus Salesforce Extension Pack integrated with command line utilities resulting in much faster Salesforce devops pipelines.
To help spread the word about this fantastic development, and to chime in with my comments and observations about the current state of the product, here is my detailed review of Salesforce Extension Pack for VS Code. You can check out my video review here.
Keenan Vision Scorecard Rating
Salesforce Extension Pack gets a 3.7 Keenan Vision Rating score. Here is how the product scored on each component. Be sure to check this article to see how the components are weighted for the final score.
- Ease of Use: 2
- Features: 5
- How Much Does Vern Recommend: 5
- Value: 3
- Support: 2
Keenan Vision Rating: 3.7
Pros: An essential tool for Salesforce developers, speeds devops pipelines
Cons: Hard to install, Salesforce support needs improvement
Salesforce Bridges the Gap with Salesforce Extension Pack and SFDX-CLI
SFDX-CLI is the key architectural component that connects simple scripting capabilities with many crucial metadata API and DML functions of Salesforce. Introduced in late 2017, SFDX-CLI plus VS Code integration provides a key touchpoint between the open source devops world and the Salesforce platform.
SFDX-CLI gives devops engineers a scriptable interface to a Salesforce org, which enables the orchestration of devops pipelines. Now, by marrying SFDX-CLI with the most popular interactive developer environment (IDE), Salesforce Extension Pack delivers a powerful and extensible working environment for Salesforce developers.
Salesforce Extension Pack Components
The Salesforce Extension Pack is a collection of eight separate VS Code extensions, which should be installed together by first installing the extension pack.
- Apex: The Apex Language Server
- Salesforce CLI Integration
- Lightning Web Components
- Apex Interactive Debugger
- Aura Components
- SLDS Validator: The Salesforce Lightning Design System Validator
- Apex Replay Debugger
I will cover the most used parts of the Pack for back-end development, which are Apex, SFDX-CLI integration, and the Apex Replay Debugger. One component, the Apex Interactive Debugger, only applies to partners and is not used by most developers.
Hands On Experiences
In this review of Salesforce Extension Pack, I evaluate my experiences doing these tasks:
- Create a scratch org, add metadata components, perform low-code updates, and save in new source code repository
- Use SFDX-CLI to update an Apex class in a production org without a sandbox
- Debug Apex REST with the Apex Replay Debugger
Before I get into those experiences, there are some general impressions, or frankly complaints, that need to be listed.
Front-End Development Recently Got Better
I did not formally test using Salesforce Extension Pack and VS Code for front-end development in this review. But I have set up a local development server for Lightning Web Component (LWC) development. This works by installing the “lwc-dev-server” SFDX-CLI plugin, and then running the server in another terminal window with the command “sfdx force:lightning:lwc:start”. That starts up a process that will access Salesforce data and render a page on a local HTTP port, while using the local VS Code workspace for source code.
This changes the time between saving and seeing a result from minutes to seconds. Now, when a developer saves a JavaScript, HTML, or CSS file in their project, the screen is quickly updated. By avoiding a metadata upload to the Salesforce, a front-end developer’s time may be used to produce more iterative and pixel-perfect work.
Using SFDX-CLI with NodeJS and NPM
I am sure many readers share a complaint I have about using SFDX-CLI. Namely, that I could not get the darn thing to work! I either had a problem with NodeJS or NPM or an issue about permissions. It was maddening and frustrating.
To solve this problem, I became extremely strict about how I used and installed NPM, and only used Node Version Manager to install NodeJS and NPM on Linux implementations. If I wanted to do something else with NPM, like write a React app, then I would use NVM to install a new version of NodeJS/NPM and switch to that version. Now with my strict use of NVM, I always keep my SFDX-CLI NPM installations separate from other NPM installations.
I wonder why does Salesforce depend on NodeJS for such a critical function? SFDX-CLI depends on thousands of NPM modules, and who knows when one of those modules becomes infected with a cyberattack vector!
My wish is to find a way to preserve the emerging SFDX-CLI ecosystem, but to encapsulate the utility into a single Linux/Mac/Windows binary file. I am not sure this can be done and still preserve the innovative plugins that have already emerged. But distributing a single binary file is how more modern CLIs are built nowadays with languages like Go.
Too Many Version Updates
While I appreciate good security and frequent updates, Salesforce Extension Pack requires too much attention from developers for version management. I constantly see new updates, whether it is a VS Code extension or the SFDX-CLI’s NPM installation. Salesforce Extension Pack’s need for updates greatly outpaces other major extensions, such as the Go language server or Red Hat Java.
Please do everybody a favor and slow down the version releases.
Apex Language Server is a Pain
The other installation chore that blocks many would-be Salesforce Extension Pack users is installing Java on the local workstation that runs VS Code. There is an endless variety of Java options available for Mac and Windows users, and there really are not many straightforward ways around an awkward two-step procedure to become Java-compliant.
Also, since the Apex Language Server makes extensive use of Java, which eats up memory and CPU resources, this makes Salesforce Extension Pack run slowly on all be the newest desktop computers.
I finally got the performance I needed when I got Java off my workstation. This entailed using a VS Code Remote server operating in my current network segment. See an earlier How-To article for more details on using VS Code Remote to speed up VS Code development.
Using Support for DX
I am afraid that I too have had frustrating experiences with Salesforce support. For me, the most frustrating thing is handling inbound callbacks at their convenience. Or, with myself being a native English speaker, I sometimes cannot understand what the support representative is saying. Sometimes even the VoIP quality just seems bad!
I have had an occasion to call Salesforce Support about an issue I was having with the Apex Replay Debugger. I later discovered my problem was metadata synchronization issue of my own making, but that was after spending time with Salesforce support that was not productive.
In general, if a new Salesforce developer is not part of a larger company, a local user group, or other self-help resource, hitting roadblocks and error messages when working with Salesforce Extension Pack can be very frustrating.
Create a New Scratch Org
Creating new scratch orgs worked smoothly with no problem by following examples in the Salesforce documentation. Again, this was accomplished only after following a strict SFDX-CLI and VS Code installation and setup procedure.
The idea behind the Salesforce Scratch Org is to create a Salesforce environment with a very restricted set of metadata behind it. So little, in fact, that any good Salesforce developer should be able to read every file and understand why it is in a metadata update package. That is why Scratch Orgs are ideal for creating 2nd generation packages and other forms for source-based Salesforce development.
To get started I created a new SFDX project with no special flags. Next, for me to create a new Scratch Org it must be linked to a Salesforce Dev Hub. If you do not have a Dev Hub you can setup a new one for free using a Salesforce Developer account.
Using my standard SFDX environment, I used the remote device login procedure to authenticate my session for creating scratch orgs. I then used these commands to generate and open a new scratch org:
sfdx force:org:create -f ./config/project-scratch-def.json -a render-dx –setdefaultusername
sfdx force:org:open -u render-dx
A CTRL-<Click> on the generated URL opened the org in my default browser window. To test my new Scratch Org setup, I created some metadata changes, and then copied some Apex Classes into my development directory. I was able to synchronize my local copy of the project with the scratch org using the “sfdx force:source:push” and “sfdx force:source:pull” commands.
Finally, I was able to save my work on a new GitHub repository so it may be shared with other developers using the VS Code integrations with GitHub and GIT.
Update Existing Org
Using SFDX-CLI I downloaded metadata for an existing production org, updated Apex classes, and then deployed the metadata back to the production org directly, invoking Apex tests, without a sandbox.
This technique is a useful way to use Salesforce Extension Pack for org maintenance. For this part of the review, I created a new project with SFDX-CLI that downloads a pre-programmed subset of metadata from an existing org using these commands:
sfdx force:project:create --projectname=mybranch –manifest
cd mybranch
sfdx auth:device:login --setdefaultusername --setalias myUser
sfdx force:source:retrieve --manifest=manifest/package.xml
I then used VS Code to modify the downloaded metadata and Apex code. Later, I successfully uploaded those changes to my production org using this command:
sfdx force:source:deploy –testingflag goes here
Use Apex Replay Debugger
One of the most frustrating moments in any developer’s workday is when an impossible bug arises. After you have tried writing out log files and other tricks, it is finally time to break out the symbolic debugger to examine the execution of an Apex class step-by-step.
Since regular users cannot gain access to a real, live debugger session in a Salesforce tenant, there is something that replaces it called the Apex Replay Debugger. This is where you can set the Apex debug log to generate enough information that it exactly describes what is happening with every variable and statement in an Apex procedure call stack. Sounds handy, right?
I was able to use the Apex Replay Debugger in VS Code using a remote SSH server in a gigabit LAN. I used VS Code commands to download debug logs, load them up for a debugging run, set breakpoints in my Apex code, check memory values, and other debugging tasks.
I find the Apex Replay Debugger to be invaluable. This is especially true when tracking down issues with Apex code I use in a REST endpoint.
Conclusions
Salesforce Extension Pack delivers on its promise to augment VS Code, which makes it a powerful and productive platform for day-to-day Salesforce developer activities. With Salesforce Extension Pack installed, using VS Code and Salesforce CLI (SFDX-CLI) dramatically increases a developer’s productivity when compared to using Eclipse or the Developer Console.
There is still plenty to improve upon, such as the awkward installation procedure and other glitches that can turn into showstoppers. I wish that Apex language server were more lightweight, and that Java was not needed as well. And please slow down with all the versions!
Despite any ratings or other reservations, I wholeheartedly recommend that all new and existing Salesforce developers immediately adopt the best, free Salesforce development system available. Hopefully by seeing how using these tools improve the daily workflow of a Salesforce developer, you and your team members will be inspired to make the leap to the future today.
