Debugging VueJS + TypeScript with VS Code - Part 2

16 March 2022

In the past I have written about how to setup VS Code to debug a VueJS + TypeScript project. Since writing that article it's a method I've continued to use and it works well. It's quick to spin up and quite reliably allows you to place breakpoints in code.

However one aspect of it that I don't like is it's not so much "Run and Debug" from VSCode, it's more just the debug part, as to use it you must first go to a terminal and run your VueJS application.

There's two problems with this:

1. Most of the time you will just run the application not debugging (because why debug when you don't have an issue), therefore when you need it, you have to redo what you just did that caused an error. Instinctively there is then a desire to guess at what was wrong rather than going to the extra effort of debugging (frequently when you do this your guess is wrong and you end up spending more time guessing at what was wrong than using the tool that will tell you).

2. As the debugger generally isn't running, exceptions never get flagged up, and unless you have the browser console open (and check it), you can remain oblivious to something going wrong in your app.

There is a solution though, and it's quite simple!

Using VS Code to launch via npm

First follow through my previous guide on debugging a VueJS and TypeScript application.

Next, in your launch.config file add a new configuration with the definition below. This will run the command in a debug terminal, effectively doing the same thing as you typing npm run serve.

1{
2      "command": "npm run serve",
3      "name": "Run npm serve",
4      "request": "launch",
5      "type": "node-terminal"
6    },

To get both our new and old configuration to run you can add a compound definition, that does both at the same time.

Here's mine.

1"compounds": [
2    {
3      "name": "Run and Debug",
4      "configurations": ["Run npm serve", "vuejs: edge"]
5    }
6  ],

My complete file now looks like this. Note you don't need configurations for edge and chrome, just use the one for the browser you use.

1{
2  // Use IntelliSense to learn about possible attributes.
3  // Hover to view descriptions of existing attributes.
4  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
5  "version": "0.2.0",
6  "compounds": [
7    {
8      "name": "Run and Debug",
9      "configurations": ["Run npm serve", "vuejs: edge"]
10    }
11  ],
12  "configurations": [
13    {
14      "command": "npm run serve",
15      "name": "Run npm serve",
16      "request": "launch",
17      "type": "node-terminal"
18    },
19    {
20      "type": "pwa-msedge",
21      "request": "launch",
22      "name": "vuejs: edge",
23      "url": "http://localhost:8080",
24      "webRoot": "${workspaceFolder}",
25      "breakOnLoad": true,
26      "sourceMapPathOverrides": {
27        "webpack:///./*": "${webRoot}/*"
28      },
29      "skipFiles": ["${workspaceFolder}/node_modules/**/*"]
30    },
31    {
32      "type": "chrome",
33      "request": "launch",
34      "name": "vuejs: chrome",
35      "url": "http://localhost:8080",
36      "webRoot": "${workspaceFolder}",
37      "breakOnLoad": true,
38      "sourceMapPathOverrides": {
39        "webpack:///./*": "${webRoot}/*"
40      },
41      "skipFiles": ["${workspaceFolder}/node_modules/**/*"]
42    }
43  ]
44}
45

Now whenever you want to run the application, just run the compound Run and Debug and your VueJS app will start up and launch in your browser.

Debugging VueJS + TypeScript with VS Code

18 March 2021

I recently asked a developer working with VueJS how they do debugging and they told me console.log. Not wanting to go back to the dark ages of development I went and found the solution myself.

The VueJS website has a guide on how to do debugging with VS Code https://vuejs.org/v2/cookbook/debugging-in-vscode.html however the instructions they give don't work with TypeScript. Interestingly it does get you far enough to set breakpoints within either Chrome or Edge, but I don't really count that as a solution. The idea of debugging is you step through your code and see everything that is happening, not step through a copy of your code and then go and find the corresponding file in your code editor.

After a bit of digging I managed to get it to work, so here's my solution.

Prerequisites

This part is essentially as per the VueJS guide.

Make sure you have VS Code installed and install the Debugger for Chrome. Don't worry if you use Edge, the same extension will work.

Create your project with the vue-cli, following the instructions in the Vue CLI Guide. When you do this make sure you pick Typescript.

Displaying Source Code in the Browser

This isn't what we're after but it's still a step we must do.

Create a file called vue.config.js in the root of your solution and paste the following into it. This creates the mapping for the debugger to map compressed files back to the original.

1module.exports = {
2  configureWebpack: {
3    devtool: 'source-map'
4  }
5}

Configure debugging from VS Code

In VS Code select the Run and Debug button on the left and click the Run and Debug button. If you don't see this button it probably means that you already have a launch.json file defined. Instead a cog will appear at the top to edit the existing settings.

From the options choose either Chrome or Edge.

This will create a launch.json file with some defaults filled out. Replace the contents of the file with the below (this is the part which differs from the instructions on VueJS's site).

I have included 2 configurations, one for debugging with Chrome and the other for Edge. They are both essentially the same and just launch a different browser.

1{
2  // Use IntelliSense to learn about possible attributes.
3  // Hover to view descriptions of existing attributes.
4  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
5  "version": "0.2.0",
6  "configurations": [
7    {
8      "type": "pwa-msedge",
9      "request": "launch",
10      "name": "vuejs: edge",
11      "url": "http://localhost:8080",
12      "webRoot": "${workspaceFolder}",
13      "breakOnLoad": true,
14      "sourceMapPathOverrides": {
15          "webpack:///./*": "${webRoot}/*"
16      },
17      "skipFiles": [
18          "${workspaceFolder}/node_modules/**/*"
19      ]
20    },
21    {
22      "type": "chrome",
23      "request": "launch",
24      "name": "vuejs: chrome",
25      "url": "http://localhost:8080",
26      "webRoot": "${workspaceFolder}",
27      "breakOnLoad": true,
28      "sourceMapPathOverrides": {
29          "webpack:///./*": "${webRoot}/*"
30      },
31      "skipFiles": [
32          "${workspaceFolder}/node_modules/**/*"
33      ]
34    }
35  ]
36}

Debug from VS Code

To start your debugging you still need to start the application from a terminal with npm run serve. The debugging experience is more like Visual Studios attaching to a process rather than running application by clicking start.

Once your application is running, to attach the debugger either press either F5 or go to the run and debug tab, make sure your browser of choice is selected and click the green play button. Your browser of choice will now open and VS Code should be attached and any break points you create will be hit.

JavaScript frameworks explained to an ASP.NET dev

8 February 2021

For most of my career I've been an ASP.NET dev and a JavaScript dev. If I was going to say I was more of an expert in one of them it would be the .NET side of things but I've never really lost touch with JavaScript.

Right now I think it's fair to say technologies in the world are starting to shift how we build websites, with JavaScript frameworks reaching a point with features like static site generation where they actually now offer a decent performance incentive to use them. At some point Blazor may get to a point where it reverses this, but right now there's a compelling argument to move.

For a ASP.NET dev this can be a daunting task. You might be thinking of trying out a headless CMS with a JavaScript front end, but just take a look at this screen grab from Prismic's sdk list.

There's 7 different JavaScript based SDK's listed there! Over half of the total and none of them are that Angular thing you had heard about. Where do you start?

Lets compare to .NET

Well recently I've been updating my JS skills again trying out some of the frameworks I hadn't used before, so I thought I'd share some learnings. The good news is as always it's not really as different as it first seems. To take some of the pain out of understanding what all these frameworks are I thought it would be good to try and relate them back to .NET and what the almost equivalent is.

Assembly Code

No not actual assembler but what does our code actually compile to. In the .NET world we have CIL (Common Intermediate Language), previously known as MSIL (Microsoft Intermediate Language) that our C#, F#, VB etc all compile down to before then being converted to the correct machine code for where they run.

In the front end world think of JavaScript being a bit like this (apart from the fact you actually write JavaScript and we don't write CIL).

View Engine

To render views into HTML, in the ASP.NET world we have Razor, but not just Razor. We also have WebForm, Brail, Bellevue, NDjango (see more here), it just happens that we mostly just use Razor.

I see the equivalents of these being ReactJS, VueJS and Angular. Its not an exact match as they also aren't exact equivalents or each other, but they're largely your functionality that will take a model and turn it into HTML.

Web Application Framework

The problem with the name framework is it applies to basically anything, but this is what I'm going with for describing ASP.NET MVC/ASP.NET Razor Pages/Web Forms, you know all those things built on-top of .NET that make it a website rather than a desktop app. They do things like routing, organising our files into controller and view folders, know how to respond to http requests etc.

Here we have Next.js, Nuxt.js and maybe Gatsby. The link between these and View Engine is a bit stronger than the ASP.NET MVC world as you essentially have a one to one mapping Next.js -> React, Nuxt.js -> Vue but they are what adds routing, static site generation and organization to your code.

Lower Level Framework

Now this one could be wrong :)

In .NET we have different version of the framework. e.g. .NET Framework /3.5/4, .NET Core, .NET 5, Mono. On the front end side they have Node.

Languages

In .NET we have choices including C#, F#, VB among other.

JavaScript has JavaScript (which I know I said was assembly), TypeScript, Coffee Script maybe more.

Not so daunting

There's probably a bunch of flaws with my comparison list and reasons people can point out why things I've said are the same are in fact different, but my point was really to show that while .NET may appear as one button on a SDK list alongside 7 JavaScript based SDK's its not that different. Out of the 7 Node is based on JavaScript. Vue and React are based on Node, and Next/Gatsby/Nuxt are based on Vue/React. There just isn't the same concept of all of it being built by one company or one particular combination being dominant in the same way that ASP.NET MVC + C# + Razor has been for the last generation of .NET websites.