So confession. I am like using and am quite comfortable using the Force.com IDE/Eclipse and even Developer Console when I do dev work. Have I used VS Code for Salesforce before? Nope! Force.com IDE is my go-to and I have been using it for a number of years…
But as you may have picked up, Salesforce has been starting to push users to switch over to VS Code with the retirement of the Force.com IDE v2 beta in Spring ’18 release.
Additionally to develop with features like Salesforce DX, you need to switch to VS Code. So let’s take a look at what VS Code is, how to get it setup and how to deploy your first class to a sandbox…
What is VS Code?
Firstly, if you haven’t heard of VS Code (or Visual Studio Code). It is a light-weight, open-source, code editor. And it is optimised for building and debugging modern web/cloud applications.
The core features include:
- Intelligent code completion
- Syntax highlighting
- Embedded GIT control
- Support for debugging
- Extendable via plugins/add-ons (which is how Salesforce comes into the picture)
It is a free tool to download, and runs on most major Operating Systems (Windows, Mac, Linux). And isn’t based on Java, instead using the Electron framework to build cross-platform desktop support, essentially using web technologies.
Most importantly, don’t confuse it with Visual Studio which is used primarily for .Net related programming languages and is only available on Windows.
What’s behind the change?
Well, the simple answer, is that VS Code was an easy platform to use, to give Salesforce the Command Line interface needed for Salesforce DX development via a VS Code plug-in.
But personally I feel, there is a bigger motive behind what we are now seeing over the last year or two for Salesforce re: platform development (and features like Salesforce DX becoming available)…
Most Dreaded Platform…
See, historically Salesforce has been receiving overall negative reviews from Developers, and has typically featured in the top 5 (if not the top position) of ‘most dreaded’ lists from yearly developer surveys on sites like StackOverflow.
The surveys since don’t fare much better, including the latest 2018 survey with Salesforce in the top 3 ‘most dreaded’…
Personally, when talking to a number of .Net developers over the years, I am not surprised by these results. Even though APEX is similar to other languages, there are a number differences between developing for a cloud-based platform like Salesforce vs a .Net application. And there needs to be…
But things like Salesforce governor limits, take on a huge focus when developing for Salesforce (hello, bulkification), and it does force you to think differently about how you solve a problem. But I digress…
Additionally, the fact most developers don’t use Eclipse as an IDE… But instead prefer to use VS Code as a development environment, we can start to see why Salesforce is heading in the direction it is:
Additionally we are seeing a renewed focus from Salesforce on improving the overall development experience over the last few years. Features like Salesforce DX/scratch orgs, Lightning Components (using more standardised web-development languages, eg Javascript) and now with Spring ’19, Lightning Web Components.
Salesforce is clearly making a play to smooth the development experience for developers, primarily for other web-platform developers, who aren’t familiar with Salesforce.
Why? Well, in my opinion by implementing a way to allow someone to develop on Salesforce, but with no specific Apex/Visualforce knowledge, they are growing the overall developer market and making the platform more flexible overall for developers.
What does VS Code offer Force.com Developers?
So that is it for the history lesson part of this write-up! Now let’s take a look at what VS Code might offer us Force.com Developers who are used to Force.com IDE…
The main take-aways for me out of the video are:
- Track changes easily to source XML
- Replay Debugger, being able to ‘step through’ the code now and see variables at runtime, all based on the debug logs. This is relatively new thing for Salesforce, but is common in other development languages. And will streamline how you handle debugging of processes
- Support for Scratch Orgs vs ‘normal’ Sandboxes/Production
- Scratch Orgs give you a disposable/throw away development environment and can be spun up instantly. (Think Salesforce DX).
- Package Development Model, is similar to what you are probably used to in Force.com IDE, allowing you to push/pull into development/trial sandboxes or production environments.
How-to Guide: Getting Started with VS Code
So let’s go…
When I was trying to install and get my development environment setup I had to jump around to multiple sites to try and figure out how everything works together. So I am trying to collate this all into one spot as I learn myself…
But please note, as I am going through and teaching myself about VS Code and writing this, there may be quicker ways to do things. If you have any of these tips, please feel free to add them in the comments section at the end of the article!
Gettings Started #1. Installing and setting up VS Code
Downloading and installing VS Code
First up, you will need to download VS Code. I will assume your machine can handle VS Code… And it is free and available to download for Mac/Windows/Linux from here.
Setup VS Code for Salesforce
You will also need to install the Salesforce CLI package, as the Salesforce extensions for VS Code (the next step) require this package to be installed on your machine. So jump over to here to download and install it.
Salesforce Extensions
The final step to getting VS Code up and running, and before we start on our first project, you will need to also install the Salesforce Extensions for VS Code.
These are freely available in the VS Code ‘marketplace’ (think the App Exchange for Salesforce, or Chrome Web Store for Chrome Extensions).
Click here, and click the green ‘Install’ button. You should then be prompted to open the link in VS Code. You will then see another pop-up with ‘Install’ button. Click it, and then VS Code should install/restart.
Other Extensions
There are a number of other Salesforce related extensions available. I won’t cover them here, but you can easily search the Marketplace and find other relevant extensions/packs.
This is one advantage of being an open-source platform, anyone who wants to can develop and share an extension/plugin if that wanted to…
Learning Basics of VS Code
To learn the basics of VS Code, Microsoft has a ‘Get Started’ section on the VS Code website. These video cover the basics of:
- Navigating around VS Code
- Debugging
- Using Intellisense (the code completion/suggestion feature like Content Assist in Eclipse)
- Version Control (using VS Code with GIT)
My first impression was a little confronting. This might not be the case if you are use to command line development (CLI), but after coming from Eclipse where most things are point and click, it was a little bit of ‘gee, what do I do now?’
The main thing to learn and start to get comfortable with is the Command Palette, as this is how you will navigate and access the commands within the tool:
I would urge you to take a look at the Tips & Tricks page from Microsoft on VS Code too. It includes print outs of the keyboard shortcuts and a number of other useful details.
Getting Started #2. Creating your first Project
There is a useful Wiki published on the Salesforce DX Github page, and it outlines the types of projects you can work (scratch orgs vs developer/trial sandboxes/etc) and how to get started with the various Command Palette commands.
The two models you should be aware of (sourced from the below guide on GitHub) are:
- Org Development Model – which is similar to what you are probably doing now if you use Force.com IDE. And is where you connect to an environment (eg Sandbox, Developer, Trial, or Production org) and then develop/deploy code directly into that environment.
- Package Development Model – is the second type of development model and this is where you would ultimately connect to a scratch org for development. To read more about this, click here.
The commands you use in the Command Palette will depend on the development model you are trying to setup and code with… There is a full guide for both development models here.
But for the purposes of this post though, I am going to setup and connect to a Developer Sandbox via the Org Development Model.
Open the Command Palette
To get started, open the Command Palette (on a Mac, which I am using press CMD+SHIFT+P), and in the Command Palette type in:
SFDX: Create Project with Manifest 
Then, the Command Palette will ask you for the name of your project, so type in a Project Name and press enter. I am just calling this ‘My First Project’ for this guide…
Then you should get a pop-up window asking you to confirm the location to save it on your local machine. (This is similar to the Workspace location in Force.com IDE).
In the pop-up window, confirm the folder location and click ‘Create Project’:
You will then see your Project open in the Explorer (on the left hand side):
Getting Started #3. Find your sfdx-project.json file
This file should have created as part of the project, and is where you store the configuration information, like which environment you want to connect to.
You can read more about this file here or here.
For this demo, I will update the URL to login to a sandbox to https://test.salesforce.com, and save the changes to the file:
"sfdcLoginUrl": "https://test.salesforce.com",
Gettings Started #4. Let’s get connected…
We need to start the process of essentially connecting and logging in to the environment we want to login to.
Now, open up the Command Palette again and type in:
SFDX: Authorize an Org
As you type, you will now see a number of new SFDX commands available too. But for now, just select the Authorize Org option and press enter.
The Command Palette will then prompt you for which environment type to login to. You can select ‘Project Default’ as we already updated the sfdx-project.json file already.
And then you will also be prompted for an Org Alias, you can press Enter and accept the default name, or specify a custom alias.
Now, VS Code and the Salesforce Extension will open up your browser and take you through the normal login flow. In this example, I have Lightning Login also setup (just to demo that this also works).
As you go through the login, if this is the first time for the environment you may also see a ‘Global Connected App’ authorisation, just click Allow.
Meanwhile, back in VS Code, you should see a little pop-up on the bottom right hand side now confirming login has been completed:
Getting Started #5. Retrieve your Source
Now we are authorised, we can go ahead and look and downloading our source components.
You will need to first check you package.xml, which is where information on what to download/retrieve is stored. You can find the documentation on the .xml file here.
But imagine this step, being similar to Force.com IDE where you select which components you want to download from the environment.
And keep in mind, this step is only for when you connect to a developer, trial, production environment. If you go and use scratch orgs, you won’t have to do this step.
In the Explorer under your Project, find the folder ‘manifest’. This is where you will find the Package.xml file.
By default, it includes the APEX components, Aura Bundles and Static Resources, but you can add to it if you wish.
Now with the Package.xml ready, you can commence the download/retrieval of the elements.
Here, instead of using the Command Palette, you will need to right-click on the file in the Explorer, and select the option:
'SFDX: Retrieve Source from Org'
Gettings Started #6. Work with your code…
You will get another little notification once it has completed downloading, and now you can navigate to the code!
Navigate via the Explorer, to force-app -> classes -> find the Apex Class you want to work with and double click on it to open the editor. Then this part should feel very similar to Eclipse.
Now you can start your coding. To use features like Intellisense (the auto-suggestion feature), you can select CTRL-Space (on Mac, though I assume similar on Windows) to up the pop-up:
As you you coding too, you will see in the bottom left hand side of the screen an Errors and Warning notification. You can simply toggle the Panel to display by clicking on the icon (or CMD-J on Mac).
This Panel, then displays the Problems, Output, Debug Console and Terminal (if you need them).
Problems via the Panel will look very familiar to you if you have used Eclipse (or Developer Console):
Gettings Started #7. Deploying your code back to Sandbox
And finally, when you are ready to push the code back to the server. You can right-click on the class again, and then select ‘SFDX: Deploy Source to Org’.
SFDX: Deploy Source to Org
Getting Started #8. Deploying to Production?
Salesforce don’t recommend using the above ‘Deploy Source to Org’ to move things into Production. Instead they advise developers to use the Packaging feature.
For now, this is just a how to get started guide… But if you are ready to move your code to a Production environment, please read more about this over here.
Extra Reading: Migrating from Force.com IDE to VS Code
The final guide for you, is if you want to migrate your workspace and projects over from Force.com IDE. into VS Code
Salesforce has included instructions you can follow, to migrate your packages into VS Code. To read more, click here.
Wrapping up
So this is just the start. But we have now connected to a sandbox, worked with our first Apex Class and Deployed it back into the Sandbox.
There are a lot of other features which will be covered in another post shortly (like working with source control/repository and debugging). But for now, happy coding!
And as I mentioned at the start of the guide, if you have any shortcuts / tips or suggestions, please add them in the comments below!