

I love JetBrainsβ IDEs. Iβve been a faithful user since PyCharmβs release, seven years ago.
As of late, if Iβm watching a presentation, and someone is writing code in an editor, that editor is almost always VSCode.
Somethingβs up, and Iβm going to get to the bottom of it. People rave about this thing.
Iβll answer some questions for myselfβββand, with luck, maybe I can save the JetBrains-faithful some time and energy. I aim to discover:
Iβll be looking at this from the standpoint of a JavaScript developer, so Iβll write βWebStorm,β but I really mean βa JetBrains IDE.β
Iβm certainly interested in how VSCode handles Python and C/C++, but Iβm not going to explore it in this post.
I used Homebrew Cask to install it:
$ brew cask install visual-studio-code
==> Satisfying dependencies
==> Downloading https://az764295.vo.msecnd.net/stable/f88bbf9137d24d36d968ea6b2911786bfe103002/VSCode-darwin-stable.zip
==> Verifying checksum for Cask visual-studio-code
==> Installing Cask visual-studio-code
==> Moving App 'Visual Studio Code.app' to '/Users/boneskull/Applications/Visual Studio Code.app'.
==> Linking Binary 'code' to '/usr/local/bin/code'.
πΊ visual-studio-code was successfully installed!
This takes ~4s on my 2016 MBPβββbut I donβt have any extensions installed yet.
Iβm greeted with this:
It has also opened a web page in Chrome:
I ignore the web page (thanks, but no thanks) and click a few of the βInstall support forβ¦β links under Tools and languages to get some basic extensions installed. I want to avoid customizing too much at the outset. Since C/C++ isnβt listed on the βWelcome Pageβ, I dig into to the extensions andΒ β¦ canβt help myself from installing a bunch of extensions. Oops.
I am, however, elated to report that the JetBrains IDE Keymap is a thing, and it works great.
I go ahead and open up my Mocha working copyβ¦
OK, so I want to edit MochaβsCHANGELOG.md
. But I know origin
has changes I need to pull.
Happily, VSCode understands this is, in fact, a working copy. To pull, I found a little βrefreshβ button in my status bar, and clicked it. I think it worked? It said βsync.β Whatβs a βsyncβ?
Iβm unsure what just happened. Which changesets did Git pull? I want to look at the history. After searching in vain, I realize that there is no built-in support for Git history, and Iβm going to need to grab an extension for this.
GitLens seems to solve this problem (and others). But there are many Git-related extensions for VSCode. This is a drawback of the βsmall coreβ philosophy of VSCode (this reminds me of the Node.js ecosystem). To VSCodeβs credit, it aids discovery with tags, filters and sorting.
GitLens does some oddball things like βinline blameβ and βcode lensβ (which is another view into βblameβ? I donβt get it). I want to turn this noisy stuff off.
Hint: run GitLens: Toggle Code Lens
and GitLens: Toggle Line Blame Annotations
from the Command Palette.
GitLens then provides Git history in the left sidebar. The presentation of the repo is a little disorienting (there are so many trees, itβs like a forest), but I do see the pulled changesets.
Whew.
Iβve made my changes to CHANGELOG.md
, and itβs time to commit. VSCode helpfully marks the file with a big M
in the file list. +1.
I find Git: Commit
via the Command Palette, and realize I could have used my trusty β-K
. But Iβm prompted that the stage is empty.
If you only use WebStormβs built-in version control client (I donβt), this will be culture shock. VSCode uses the stage, like literally every other Git client except WebStormβs.
I go ahead and commit everything (including unstaged changes; this would be Git: Commit All
if I wanted to avoid the prompt), and push.
Not the nicest initial experience, but Iβm confident itβll be smoother sailing from here.
Next, Iβll run Mochaβs test suites to prepare for publishing.
I think a βTaskβ is perhaps a βRun Configurationβ or βExternal Toolβ.
βTasksβ are not the same as βTasksβ in a WebStorm, which is WebStormβs (leaky) abstraction around issues, staged changes and branching.
Letβs see what βConfigure Tasksβ doesβ¦
Ooook. that needs some further explanation, but sure. Is it trying to automatically detect my npm scripts? For reference, Mochaβs scripts
in its package.json
is literally just:
{
"scripts": {
"prepublishOnly": "nps test clean build",
"start": "nps",
"test": "nps test"
}
}
Iβll roll the dice with npm: test
.
VSCode creates and opens aΒ .vscode/tasks.json
file:
Fascinating. I click the link and learn about this file. Itβs unclear whether VSCode intends for the user to commitΒ .vscode/
to VCS (I donβt do so; in fact, I addΒ .vscode/
to myΒ .gitignore
post-haste).
VSCode likely didnβt need me to βconfigureβ the Taskβββit discovered the script itself. I execute Run Taskβ¦
, choose npm: test
, and the output opens in a terminal, as youβd expect.
Iβm now certain βTasksβ are analogous to βExternal Toolsβ. Like in WebStorm, the user (seemingly) cannot debug a Task, and thereβs little integration. VSCode ships with some helpers for common build tools (unfortunately, nps is not one of them). Like WebStorm, the user has free rein to create a βshellβ-based Task.
Iβm still looking for the analog of a βRun Configuration,β which appears to be a βDebug Configuration,β though itβs just called βConfigurationβ under VSCodeβs βDebugβ menu. Next, Iβll take it for a test-drive. Whatever the hell itβs called.
.vscode/
to VCS. Iβve never had success committing any sliver ofΒ .idea/
to VCS, but maybe the story is different here. Donβt look at me; find some other guinea pig.Trivia: VSCode recognizes the filetype of tasks.json
as βJSON with Commentsβ, which, AFAIK, is unadulterated, imaginary nonsense. Is it JSON5 or not?
First, I install the Node.js Extension Pack, since I figure Iβll need it to debug properly.
From VSCodeβs menu, I open Debug > Open Configurations
. Iβm presented with a new file,Β .vscode/launch.json
. Like tasks.json
, this is my config file.
This menu item inexplicably corresponds to the command Debug: Open launch.json
.
Do you want the good news or bad news first? I donβt care.
The bad news is, I canβt just throw npm test
in launch.json
and expect my breakpoints to get hit. Why not? Because npm
spawns nps
, which spawns ten different mocha
processes in series, each which spawn _mocha
, and many of which spawn _mocha
again.
This is by no means VSCodeβs fault, but the story around debugging subprocesses in Node.js is a sad one. Iβd be foolish to expect a miracle.
The good news is that if I choose some subset of the tests to run with bin/_mocha
, debugging works well (unless I want to debug more child processes). Itβs a solid debugging experience, though lacking some of the bells & whistles of WebStormβs debugger.
Debugging tests with Karma, awkward is.
In a WebStorm, you create Karma-based run configuration, point it to your config file, specify any particular browsers or other extra options, and push the button. It works well, even if you happen to be bundling your code with karma-browserify, which Mocha is.
This is the VSCode experience:
chrome
debug configuration identical to:{
"type": "chrome",
"request": "attach",
"name": "Attach to Karma",
"address": "localhost",
"port": 9333,
"pathMapping": {
"/": "${workspaceRoot}/",
"/base/": "${workspaceRoot}/"
}
}
karma.conf.js
(ugh, really?) to add a custom launcher to your setup object. The port below must be the same port as above. Hope itβs not in use!{
customLaunchers: {
ChromeDebug: {
base: 'Chrome',
flags: ['--remote-debugging-port=9333']
}
}
}
karma start β-browsers ChromeDebug --auto-watch --no-single-run
. Leave it running.At this point, you can set breakpoint(s) by clicking in the editorβs gutter, though they will not immediately be enabled.
There appears a small, odd, quasi-movable toolbar near the top of the window. Within this impish toolbar is a βrefreshβ-looking button; click it to re-run the tests. VSCode will then be able to discover which scripts/files Karma loaded. If youβre lucky, itβll even hit your breakpoint!
The above took a solid hour to figure out, even with a few scattered examples out there.
The last thing I want to evaluate is VSCodeβs βIntelliSenseβ capabilities.
Assuming you use ESLint, install the ESLint extension.
In terms of inspections, I just want ESLint to run on my JavaScript. I donβt need any other inspections, so I disable all the random crap WebStorm ships with.
The ESLint extension βjust works,β and the user sees the same type of inline inspections as from ESLint within WebStorm, right down to the intentions, like βFix file with ESLintβ.
The Node.js Extension Pack provides some npm-related βIntelliSense,β which knows important stuff about package.json
, like if a package is missing or extraneous, will tell you so, and automatically fix it for you via an intention.
Is βIntelliSenseβ a trademark or something? Itβs a Microsoft-ism, right? I am pretty sure I hate this word.
I believe VSCode uses TypeScript definitions under the hood (not just in TypeScript files) to inspect code, at least in part. This results in extremely accurate and nearly instantaneous code completion, jump-to-declaration, and the like. If thereβs any βkiller featureβ for JavaScript developers, itβs this. You can coax such behavior out of WebStorm, but it will still be much more sluggish.
A βdeep diveβ into this would be an excellent source of information for WebStorm users (think: CSS, HTML, TypeScript, template languages, etc.), but is unfortunately out-of-scope. Iβll end with my final thoughts below.
Visual Studio Code is better than I expected. Itβs comparable with WebStormβββby way of extensionsβββin terms of feature set. It has a couple notable advantages over WebStorm, however:
Notable disadvantages include:
As a developer, my code editor my most important tool. Having spent many years with JetBrains and WebStormβββand having very little dissatisfactionβββa different tool must be incredibly compelling for me to want to pick up.
My advice for WebStorm users? Donβt try VSCode unless you are prepared to switch.
This article originally appeared March 9, 2018 on boneskull.com.
Create your free account to unlock your custom reading experience.