Skip to content

Debugging JavaScript

Apolo Pena edited this page May 6, 2021 · 5 revisions

Overview

Eventually in a project's lifecycle, the need to debug JavaScript runtime issues can arise. VS Code has a really nice built-in debugger which can be used to debug JavaScript. The approach you will take to debug JavaScript with a debugger will depend on the type of JavaScript you want to debug. There are two main types of JavaScript:

  • server-side JavaScript
    • This is essentially node.js code and does not run in the browser.
  • client-side JavasScript
    • This is any JavaScript that is running in the browser.

Debugging server-side JavaScript

You can debug node.js code using the VS Code debugger. Have a look at this example for more information.


Debugging client-side JavaScript

Developing in the cloud requires running VS Code from a Docker container, hence, using the VS Code debugger to debug client-side JavaScript is not currently possible without impratical (VNC) or untested methods such as ngrok. Have a look at this post for more details regarding this limitation. Solving this issue is on the Gitpod roadmap and is expected to be rolled out into production in a Q3 or Q4 of 2021.

Use the Chrome DevTools debugger for debugging client side JavaScript

It is possible to use the Chrome DevTools debugger which is built into the Simple Browser VS Code extension. The Chrome DevTools debugger, of course, also comes with the regular version of Chrome so you can debug your client-side JavaScript in an external browser as well. If you are not familiar with using the Chrome DevTools debugger you can have a look at the documentation and tutorial here.

Debugging client-side javaScript in a Laravel project

Laravel uses Mix which is essentially a Webpack wrapper and API that transforms your Javascript code into something the browser can use. Follow the steps below to debug your client-side JavaScript (such as a React or Vue component) in the browser using the Chrome DevTools debugger.

  1. Enable a human readable sourceMap for Mix
    • By default your webpack.mix.js file is set up to not use source maps so you must enable them. A source map is a way to map a combined/minified file back to an unbuilt state. We must use source maps so that we can read and understand the javascript code we are debugging. Initially our JavaScript code is transformed by Mix into machine friendly code, which is something we cannot read or understand well.
    • There are many types of source maps we can use. We need to use high quality source maps that are human readable so we will tell Mix to tell Webpack to use the source-map source map which is high quality, production worthy and has the slowest build and rebuild times but allows us to view our code in its original form.
    • In your webpack.mix.js call the sourceMaps method and specify the style of source map you would like to use. Chain the sourceMaps method to the end of the existing method chain, for example:
mix.js('resources/js/app.js', 'public/js')
    .react()
    .sass('resources/sass/app.scss', 'public/css');

Becomes

mix.js('resources/js/app.js', 'public/js')
    .react()
    .sass('resources/sass/app.scss', 'public/css')
    .sourceMaps(false, 'source-map');

The first parameter of the sourceMaps method is a boolean value that determines if the source map will be used for production or not. In our case we do not need production ready source maps so we pass in false. The second parameter of the sourceMaps method is the type of source map to use. See this devtool chart for all the types of source maps available.

  1. Now that you have source maps enabled you just need to find your code in the sources panel of Chrome Dev Tools. The location of you javascript will vary depending on where the browser is running but in general you can use the below steps to find your code and set a breakpoint where you need it. Pay attention to the URL of your project workspace which will be something like aqua-swordfish-7uzsj65p.ws-us03.gitpod.io
    • Right click in the browser, choose 'Inspect'
    • Change the top tab to 'Sources'
    • Gitpod runs in an iframe so choose 'Top' from the dropdown menu on the left and begin drilling in to find the JavaScript code you want to debug.
    • Click on webpack:// in the dropdown on the left
    • Click on the . folder in the dropdown on the left
    • This file system should now look familiar. Find your code and click on it. In this example the React code for the AnswerForm that we want to debug is in resources/js/components/answer-form/index.js
  2. You can now set a breakpoint by clicking in the gutter just to the left of the line number in your JavaScript file. When your code is executed either by clicking something or refreshing the browser your breakpoint will be hit and code execution will pause, allowing you to debug your runtime issue.