Debugging tools are central to a workflow, particularly when contributing to core reproduction, writing a loader, or any other complex form of coding. This guide will take you through the utilities that are of most use when figuring out matters such as slow performance or an unforgiving traceback. These principle utilities are as follows:

• The stats data made available through Node.js and the CLI
• Chrome DevTools via node-nightly and the latest Node.js versions

The stats data can be very useful when debugging build issues, sifting through data manually, or when using a tool. It can be used to find the following:

• Build errors and warnings
• The contents of every module
• Module compilation and resolving stats
• The interrelationships between modules
• The modules contained within any given chunk

Also, the official Webpack analyze tool will accept this data and visualize it for you.

Sometimes, a more robust solution is needed when console statements simply won't do the job.

As is commonly asserted among the community of frontend developers, Chrome DevTools is indispensable when debugging applications—but it doesn't stop there. As of Node.js v6.3.0+, the built-in inspection flag can be used by developers to debug a Node.js program in DevTools.

This short demonstration will utilize the node-nightly package, which provides access to the latest inspection capabilities. This offers the ability to create breakpoints, debug memory usage issues, expose objects in the console, and more:

1. Begin by installing the node-nightly package globally:

npm install --global node-nightly

2. This package must now be run using the command line to finish the installation:

node-nightly

3. Now, using the inspect flag feature of node-nightly, we can start to debug any Webpack project. It should be noted that npm scripts cannot be run now; instead, the full node_module path will need to be expressed:

node-nightly --inspect ./node_modules/webpack/bin/webpack.js

4. The output should reveal something like the following in the command-line utility window:

Debugger listening on ws://127.0.0.1:9229/c624201a-250f-416e-a018-300bbec7be2c For help see https://nodejs.org/en/docs/inspector

5. Now, moving to Chrome's inspection feature (chrome://inspect), any active scripts should now be viewable under the Remote Target header.

Clicking the inspect link under each script will open a dedicated debugger or DevTools link for the node in a session, which will connect automatically. Note that NiM is a handy extension for Chrome that will automatically open DevTools in a new tab every time you make an inspection. This is extremely useful for longer projects.

It may also be useful to use the inspect-brk flag, which causes a break on the first statement of any script, allowing the source code to be perused, the breakpoints to be set, and the process to be stopped and started ad hoc. This also allows the programmer to continue to pass arguments to the script in question; this may be useful for making parallel configuration alterations.

One key feature that this all relates to—and something that has been alluded to previously in this guide—is the exciting subject of hot module replacement (HMR). What it is and how to use it will be covered in the following section, along with a tutorial.