- Visual Studio Code is a code editor redefined and optimized for building and debugging modern web and cloud applications. Visual Studio Code is free and available on your favorite platform.
- Electron has a launch flag -remote-debugging-port, which lets you specify a port for remote debugging. The language spoken at this port is Chrome Debugging Protocol, and VS Code has an extension that just handles that: Debugger for Chrome.
A VS Code extension to debug your JavaScript code in Electron. This is a fork of vscode-chrome-debug which automatically downloads and runs Electron. This extension does nothing which fundamentally can not be done via vscode-chrome-debug and a proper launch configuration and exists purely for convenience. Electron at that time needed street credibility and exposure as a new web development tool. It is a hybrid tool that grants web developers the ability to create desktop applications in a web environment, with ease of use. Microsoft was happy to champion their cause to get more exposure in web development circles. WPF and UWP are good enough.
Introduction
Now that you’ve converted your project to use TypeScript, it is time to update your project’s configuration so that Visual Studio Code (VS Code) can debug your application.
In this post you will:
- Learn how Electron apps run.
- Debug your main process.
- Learn how to debug with Visual Studio Code.
- Debug your renderer process.
- Configure VS Code to debug both processes at the same time using multi-target (compound) debugging!
How Electron apps run
Electron apps are split into two processes:
- Main process
- Your main.ts code (compiled to main.js) runs in the main process and is responsible for creating renderer process(es). This is the “backend”, or core, of your app.
- Renderer process
- Your index.html (and any included *.js files or other *.html files) runs in the renderer process and is the “frontend”, or user interface, of your app.
Since your app is split into two processes you must tell VS Code which process it should debug when launching your app.
Debugging your main process
VS Code has built-in support for debugging Node.js and TypeScript. Open your project in VS Code (it may automatically open your project for you).
Don’t forget to press Ctrl+Shift+B (Cmd+Shift+B on macOS) to start the TypeScript compiler.
Only a few minor modifications are required to debug the main process of your app (main.ts).
Open launch.json and make the following modifications (in bold):
This instructs Electron where your project is stored and to output debug logging to the console (these further aid debugging).
Office professional plus 2019 mac download. Save launch.json and click the Debug icon at the left of the VS Code window (picture of a bug with a slash through it) and you will see dropdown next to the gear icon has changed to reflect the new name.
Debugging with Visual Studio Code
Now try debugging the main process by:
- Opening src/main.ts.
- Setting a breakpoint on line 11: win = new BrowserWindow({width: 800, height: 600}) by:
- Clicking in the margin of the document to the right of the line number 11, or
- Placing the text caret on line 11 and pressing F9.
- A red circle should appear to the right of the line number. Press F5 to start debugging the main process.
You will notice your app’s window has not appeared yet and that line 11 is now highlighted with a yellowish tint. This is the run cursor, which shows you what line will be executed next.
Move your mouse over the win variable and VS Code will show a tooltip telling you it is null since line 11 has not executed yet. Move your mouse over path or url on the lines above and VS Code will show you the details about each object.
You can quickly inspect variables by hovering over them with your mouse cursor.
You can use the debugging toolbar that has now appeared over the file tabs in VS Code to choose different debugging actions to take (in order from left to right, keyboard shortcuts in parenthesis):
- Continue (F5) This continues execution without stopping until the next breakpoint.
- Step Over (F10) This executes the current line and moves the run cursor to the next line.
- Step Into (F11) This moves the run cursor “inside” the line being executed, so if the line being executed contains a function call, the run cursor will move to the first line of the called function and you will be able to debug the function call. If the run cursor cannot move “inside” the line being executed it will be treated as if you performed a Step Over.
- Step Out (Shift+F11) This continues execution until the end of the function call and will return the run cursor to the line being executed to either continue executing the line (if it has more function calls) or complete execution the line (if there’s nothing left to execute on the line).
- Restart This stops execution of your application and starts it again.
- Stop (Shift+F5) This stops execution of your application (ending your debugging session).
You can place multiple breakpoints in your source code and execution will stop whenever they are “hit” (encountered). Breakpoints greatly increase your ability to dig into how your application is running.
Press F5 to continue execution of your app. Your application’s window will now appear. Quitting your application will end your debugging session.
Debugging your renderer process
Before you can debug your renderer process you need to write some TypeScript code that will execute in the renderer process.
Create a new file in your src directory named renderer.ts. You will notice the TypeScript compiler creates a corresponding renderer.js file in your app directory. Enter the following code into renderer.ts:
Set breakpoints on lines 2 and 5 by placing the caret on each line and pressing F9.
Open app/index.html and add the following code before the closing tag (change [ to < and ] to >):
This will now cause Electron to load the compiled version of your src/renderer.ts file.
Now you need to update your .vscode/launch.json file to let VS Code know how to debug your renderer process. Add the following code (in bold) after your “Debug Main Process” configuration:
If there is a red squiggly underline at the opening curly brace of your “Debug Renderer Process” entry you need to add a comma after the closing curly brace of the “Debug Main Process” entry.
To enable VS Code to debug your renderer.ts file you need to ensure your main.ts file does not open the Chrome DevTools. Open your src/main.ts file and comment out line 21 by prepending it with // so it now shows:
If you open the Chrome DevTools via code in your main.ts file then debugging the renderer process will not work properly (since there cannot be two debug clients attached at the same time).
Save the launch.json file and click the Debug icon and change the dropdown to Debug Renderer Process. Press F5 to begin debugging your renderer process.
Notice your app launches without hitting the breakpoint in your main.ts file. In addition, the breakpoint on line 2 of src/renderer.ts was not hit even though that line of code has already been run (look at the console window to see the number 10). This is because VS Code’s debugger had not yet attached to your app by the time that code had run.
To debug code that is run before the renderer’s debugger has attached, launch your app and press Ctrl+R (Cmd+R on macOS) while focused on your app to reload its content (index.html). Now observe the breakpoint on line 2 is now hit. Your app’s window has become slightly dimmed and shows a message Paused in Visual Studio Code with two buttons: one for continuing execution and another to step over. Go back to your VS Code window and you will see that the run cursor is on line 2. Press F5 to continue execution and your app’s window undims. Blackjack download mac.
If you remove your window’s menu by executing win.setMenu(null) after creating it, you will not be able to use Ctrl+R (Cmd+R on macOS) to reload your content. Therefore it is recommended to leave the menu in place until you are ready to distribute your app.
Try clicking on any of the text in your app’s window. Now your app’s window becomes dimmed again and shows a message Paused in Visual Studio Code. Go back to your VS Code window and you will see that the run cursor is on line 5. Press F5 to continue execution and your app’s window undims. Close your app to end your debugging session.
Debugging both processes at the same time (known as multi-target or compound debugging)
As of VS Code 1.8.1 (released November 2016), a feature known as multi-target debugging (also known as compound debugging) was released. It allows you to run two or more configurations when debugging.
You can’t combine both of your launch configurations since they each start new instances of your app, so you must create another configuration which attaches to a running process instead of launching a new process. You also need to specify the compound to run. Add these to your .vscode/launch.json file (in bold):
Save launch.json. Click the Debug icon and change the dropdown to Debug Electron. Press F5 to begin debugging both your main process and your renderer process at the same time!
You should still have a breakpoint on line 11 of main.ts but you will notice it was not hit. This is for the same reason as when debugging the renderer: the debugger has not attached to the main process by the time the code has run. Switch to VS Code (while your app is still running) and create a breakpoint on line 28 of your src/main.ts file instead (which will be hit later). You can set breakpoints while your app is running.
If you want to debug code in your main.ts file that runs before the debugger has attached you will have to switch back to the Debug Main Process entry in the debug dropdown.
Now close your app’s window. After your app’s window disappears line 28 of main.ts is highlighted by the run cursor. Hover your mouse cursor over the win variable to see that it is not null (since the line has not executed yet). Press F5 to allow your app to exit.
If you are on macOS you may have to quit your app by using the Apple menu even though you have already closed the window.
Done!
You persevered through this long post and have learned how to debug your main process, your renderer process, and how to configure Visual Studio Code to debug both processes at the same time using compound debugging. Along the way you learned to expect some caveats while debugging Electron applications and you learned how to overcome them.
Want an easier way? Read on for how to debug shared code using Electron, Visual Studio Code and VS Live Share.
TLDR; Share an Electron session using Live Share
Here's a quick synopsis of getting a Visual Studio Live Share session working with Electron.
- Setup two Electron development environments on different machines
- Install VS Code and the Visual Studio Live Share extension
- In the main environment (Environment A), start a live share session and join it from Environment B.
- In Environment B, modify the
package.jsonfile to launch the node web server on port 4201 (or something other than the default 4200). This should be done on the local code base of Environment B, not the code base being shared in the live share session. - Run
npm starton Environment A - Run
npm starton Environment B on its local code base, not the code being shared in the live share session.
Now any participant in the live share can reload the rendered page in the Electron app and see the changes being performed in the live share.
Note: This does not actually share debugging breakpoints within VS Code, but it does allow everyone in the live share session to run the app locally with any changes made during the session.
Overview
Recently, I was on a very interesting project with a coworker that we were building using Electron and Angular 7. This was the first time I had worked with Electron and I was pleasantly surprised how efficient my workflow became. For the first time in a long time, I was able to completely develop all of the system components on my iMac Pro without having to constantly spin up different virtual machines for different components.
When running the Electron app locally, I was able to make modifications and instantly see the changes upon saving a code file using Visual Studio Code. I was able to run and debug the .NET Core api code in Visual Studio Code. I was able to run and debug the Angular web app in Visual Studio Code. Even better, I was able to collaborate with my coworker using Visual Studio Live Share. The Live Share team is constantly adding new features, and one really cool one is shared debugging of web apps. When running a web app in Visual Studio Code, Live Share is able to create a tunnel between the collaborators' machines and allow a shared debugging session to be set up, complete with the web app running on both machines! Needless to say when working in a distributed environment, this kind of tooling greatly increases the capacity for development collaboration and pair programming. After a few debug sessions, my coworker and I stumbled upon an even cooler method of utilizing Live Share and Electron..shared debugging! Well, kind of.
Setting up your environment
First things first, before diving into the details, let's make sure your environments are set up properly.
Install Node.js
I recommend having the latest version of Node from the Node download page. In this article, I tested with 11.10.0 installed.
Get the code
If you want a really quick demo, you can grab the code I use from maximegris's github which is actively being maintained. I also have a somewhat up to date fork here since I wanted to make sure I (and thus you) have a fork. The code will be needed on both environments even though you technically only need it on the host for Visual Studio Live Share. This is due to a trick I use in order to make this whole thing work, which I will explain later.
Install Visual Studio Code and the Visual Studio Live Share extension
You will want the latest versions for your operating system, which you can download from the VS Code download page. I haven't tested this on Linux, but in theory it should still work. Once you have Visual Studio Code installed, install the VS Live Share extension from the Extensions pane in VS Code.
That's it! That's all you need in order to build and run your Electron + Angular 7 app. So now, let's jump right in and get to that.
Running the app
Assuming you're using the same template that I am using in this example, getting started is very easy. There are only a few steps:
- Open the folder containing the code in VS Code.
- Run
npm install - Run
npm start
You should now have a copy of the template Electron app running on your machine! Tnefs enough download mac.
But what about Visual Studio Live Share?
Now that you've got your newly minted Electron app running, the first thing you want to do is show it off to a coworker and let them help you modify it, right!? Well let's get to it! The first step is to create a VS Live Share session. This is very simple and is done by clicking on the Live Share button on the bottom toolbar as shown.
It is simple enough for other people to join, just give them a url that will launch VS Code and join the session when they visit it.
Note: A collaborator does NOT normally need a copy of the code on their local machine in order to join a session. A guest to a live share session will have a copy of the source tree in a temporary folder. In our case, we need a local copy only because we are going to trick the locally running application into loading its content from the host's system. More details on that to follow.
Running the Electron app on the host and guest machines
This is where things go off the normal beaten path. My coworker and I wanted to be able to both run an instance of the Electron app with the code on which we were collaborating. The first thing we tried was simply running the app on both machines using npm start. This worked fine on the host, but after the app was running on the host, the electron app on the guest wouldn't launch due to an error concerning a port being in use.
> angular-electron@5.1.0 ng:serve /home/parallels/development/angular-electron
> ng serve
Port 4200 is already in use. Use '--port' to specify a different port.
After scratching our heads for a few moments, we realized that this was due to VS Live Share setting up a local tunnel from the host machine to the guest on port 4200. It does this when you launch a node web server using npm start. VS Live Share is assuming you want to be able to load the website data on all of the collaborators' machines.
This is an awesome feature of VS Live Share. It isn't limited to just sharing the node server launched with npm start. You could even use it to share a database instance on the host machine, or an api web app running on a different port, but I digress. The point is, when running the Electron app using npm start on the host machine, VS Live Share automatically sets up a tunnel for you so that your collaborators can access the renderer content that the Electron app will load. Now the only trick is to get run the Electron app on the guest machines without the port error we saw above.
Running the Electron app on guest machines, take two
After a moment of thought, we tried a slight tweak to see if we could get the Electron app running on the guest machine while loading the code on which we were collaborating. And it worked!
On the guest machine, simply modify your package.json to launch the node web server on a different port. It's extremely simple, and is done by changing two lines of code:
'ng:serve': 'ng serve'to 'ng:serve': 'ng serve --port 4201'
- and -
Visual Studio Code Electron App
'electron:serve': 'wait-on http-get://localhost:4200/ && npm run electron:serve-tsc && electron . --serve' to 'electron:serve': 'wait-on http-get://localhost:4201/ && npm run electron:serve-tsc && electron . --serve'
Save the changes to the package.json on the local copy of the source on the guests, not the package.json that is shared in the VS Live Share session. These changes are temporary as well and should not be checked into source control.
Once these changes are done, simply run npm start on the local copy of the source in a terminal or console. The Electron app should now run on each of the guest machines as well! What's more is that while the node web server is running on 4201 on the guest machines, the Electron app is still requesting its content from port 4200! This is set in one of the main.ts files and we didn't modify that.
The end result is that you can now share a VS Live Share collaboration session with many participants, run the Electron app on the host, run the Electron app on the guest machines, and then all participants will see any changes being made to the app..LIVE! See the proof below if you don't believe me.
As you can see, I have a collaboration session running with three participants; my macOS, one Ubuntu VM, and one Windows VM. I'm editing code from VS Code running on my mac, saving the edited code from VS Code running in the Windows VM and watching all of the Electron apps immediately update on all three environments.
Visual Studio Code Electron Version
This workflow was incredibly helpful when working with my colleague remotely on this project. I hope it helps you as well until this is natively supported in LiveShare itself.