Debugging Nuxt.js with VS Code
I have been using Nuxt.js recently for many different projects — work and personal. It’s a fantastic framework that really takes the pain out of SSR deployments.
A project I’ve been working on has been using the equally fantastic Firebase for backend data management, file storage, and authentication. Generally speaking, Firebase Authentication is robust and straightforward to implement. With something like Nuxt in the mix though there are several traps to fall into and various other gotchas. Very much ‘here be dragons’ territory.
One of the challenges when implementing something like authentication is that there are necessarily some parts that run ‘server-side’ and some that run on the client. I had been debugging authentication with the time-honored console.log() and I grew increasingly annoyed that VS Code has this very nice debugger that would super useful for this exact task if only I could convince it to work with Nuxt.
For whatever reason, there isn’t a ton of documentation or information on how to do this successfully. And what there is, is somewhat fragmented and full of hoary ‘works for me’ lore. The best I found was this somewhat older article by Marshall Thompson but it is a bit outdated and I didn’t like some of the particulars of that solution.
So I present my solution and hopefully this finds its way to frustrated VS Code using Nuxt developers the world over.
The good news is that this really isn’t that big of a deal. The two key areas are some minor configuration for Nuxt itself, and then the launch.json configuration for VS Code.
Nuxt Configuration
I’ve created a sample project for this that we’ll be walking through. It is just a bog-standard app created with create-nuxt-app and should be easily adaptable to your projects.
The biggest problem when debugging Nuxt is making sure source mapping is available on both the ‘server’ and the client. For the client, we can use just a regular source-map but for the server we need a particular type of sourcemap: an inline-source-map. This adds the sourcemap as a data URL directly into the bundle so tooling does not need to fetch the map. This fetch will fail horribly.
That said, we don’t necessarily want to use inline-source-maps on the client, it’d be nice just to use the standard type. To do that, we can extend the build in our nuxt.config.js to add source maps when we are running in development mode and ensure the correct type for both the client and server.
That basically acts as the magic goo that enables the rest of this to work.
VS Code Configuration
Now, how to use this configuration to debug in VS Code. We create our launch.json file with two configurations. One for the client, the second for the server. We also include a compound configuration so we can just launch both of them at the same time for some fullstack debugging.
This configuration requires the Chrome Debugger extension in VS Code. If you would prefer another browser make sure the appropriate Debugger extension is installed and modify this as needed.
This method of setting up the launch.json means we don’t need to have some strange task defined in our package.json and we don’t need to attach to an already running instance. We can just run our fullstack debug and be ready to rock.
Prove it, buddy
I’ve published a small sample project with all that already done. It also includes a trivial server middleware to give something to set a breakpoint on to show the serverside of things.
First, we go into the VS Code debugger and launch our fullstack configuration which will spin up nuxt and open chrome in debug mode pointing to our app.
When debugging with Nuxt and VS Code you need to keep the context in mind when you are setting breakpoints. There are two debug processes running, one for the client and one for the server. To set our breakpoint in our server middleware we make sure that we select the server debug process.
Failure to do this will manifest in some weird and wild ways. Sometimes you will just get an unconfirmed grey breakpoint, other times you can find a random breakpoint set up in a component template or what have you. Just ensure the right process is selected when you’re setting these things.
So we select our server process, and we set a breakpoint in our server middleware, and then reload the page and get the following.
Well that’s cool, it breaks right where it is supposed to and we have our full VS Code debug experience and tools available to us to bring to bear on any issues we have server side.
Conversely, on the client, we set our debug process to the client, set our breakpoint in a component method and then execute the method in the browser (in the sample app’s case this is by clicking the conspicuous button) and get the following.
And there we have it. Fullstack debugging of Nuxt.js apps in VS Code. I hope you found this useful and I hope it saves some time!
