Debug node. js in the Chrome developer tools

Command-line tool Devtool, which runs the node. JS program in Chrome's developer tools.

The following records show how breakpoints are set in an HTTP server.

The tool combines the functions of node. JS and Chromium based on Electron. It is designed to provide a simple interface for debugging, analyzing, and developing node. JS applications.

You can use NPM to install it:

NPM install-g Devtool

In a way, we can use it as a node substitute for shell commands. For example, we can open a REPL (translator Note: REPL is all called "Read-eval-print Loop", which is a simple, interactive programming environment).

Devtool

This launches an instance of the Chrome developer tool with the node. JS feature Support.

We can refer to Node modules, local NPM modules, and process.cwd() built-in modules like this. You can also get copy() table() functions in the Chrome developer tools like and.

Other examples are at a glance:

# Run a Node script
Devtool App.js

To Process.stdin
Devtool < Audio.mp3

Eval it
Browserify Index.js | Devtool

Run a Node script

We can use it in the development of general-purpose modules and applications devtool to replace existing tools such as Nodemon.

--watch

This command will be launched in the console of the Chrome Developer tool, and the app.js --watch files we saved will be re-loaded (automatically) to the console via the parameters.

By clicking app.js:1 on the link, the program will take Sources us to the relevant line in the tag.

In the Sources tag, you can also tap the Cmd/Ctrl + P button to quickly search through all dependent modules. You can even review and debug built-in modules, such as those in node. js. You can also use the left-hand side of the panel to navigate the module.

Because we are able to access the Sources tag, we can use it to debug our application. You can set a breakpoint and reload the debugger ( Cmd/Ctrl + R ), or you can --break set an initial breakpoint with a tag.

Devtool App.js--Break

Here are some of the features that may not be particularly common to those who study Chrome developer tools:

• Conditional breakpoint
• Pause when there is an uncaught exception
• Restart frame
• Listening expressions

Tip-When the debugger pauses, you can tap the Escape button to open a console that executes within the current scope. You can modify some of the variables and then continue execution.

devtoolAnother feature of this is the analysis of programs like Browserify, Gulp and Babel.

Here we use console.profile() (a feature of Chrome) to analyze the CPU usage of a packaged tool.

Require (' browserify ');

Start DevTools Profiling ...
Console.profile (' build ');

Bundle some browser application
Browserify (' client.js '). Bundle (function(err, src) {
if (err) throw err;

Finish DevTools Profiling ...
Console.profileend (' build ');
});

Now we are running on this file devtool :

Devtool App.js

After execution, we can see the result in the Profiles label.

We can use the links on the right to view and debug code paths that execute more frequently.

Advanced options

Chrome will constantly push new features and experiments into their developer tools, such as Promise Inspector . You can open them by clicking on the three dots in the top right corner and then selecting Settings -> Experiments them.

Once enabled, you can tap Escape the button to bring up a panel with a Promises monitor.

Tip: In the experiments interface, if you tap the Shift key 6 times, you will be exposed to some even more experimental (unstable) features.

--console

You can redirect the console output to the terminal ( process.stdout and process.stderr ). It also allows you to import it into other processes, such as TAP prettifiers, by using a pipeline.

| Tap-spec

--And process.argv

Your script can be parsed like a normal node. js application process.argv . If you devtool pass a period () in the command -- , everything behind it will be treated as a new one process.argv . For example:

Scriptinput.txt

Now, your script looks like this:

File = process.argv[2];
Console.log ('filefile ');

Output:

File:input.txt

--quitAnd --headless

When --quit an error is encountered (such as a syntax error or an uncaught exception), the process exits silently and returns the end code 1 .

Use --headless , the development tool will not be opened.

This can be used for command-line scripting:

Renderresult. png

--browser-field

Some modules may provide an entry point for better operation in the browser. When you need these modules, you can use them --browser-field to support Package.json flag

For example, we can use Xhr-request, which "browser" uses XHR when a field is referenced.

Require (' xhr-request');

Request (' https://api. Github.com/users/mattdesl/repos ', {
True
(err, data) = {
throw err;

Console.log (data);
});

Executing in the shell:

--save
--browser-field

Now we can review the Network request in the tab:

--no-node-timers

By default, we provide global and setTimeout setInterval , so they behave like node. JS (Returning an object with an unref() ref() and function).

However, you can disable this method to improve support for asynchronous stack traces.

Devtool app.js--no-node-timers

V8 Flags

In the current directory, you can create a .devtoolrc file to perform advanced settings such as V8 flags.

{
  "V8": {
    "flags": [
"--harmony-destructuring"
]
}
}

Visit here for more details

Because the program is running in a browser/electron environment, not in a real node. JS Environment. So here are some traps you need to be aware of.

There are already some node. js debuggers, so you might want to know the difference between them.

Webstorm Debugger

The Webstorm editor contains a very powerful node. JS Debugger. If you've already used Webstorm as your code editor, that's great for you.

However, it lacks some of the features in the Chrome developer tools, such as:

• A rich and interactive console
• Pause when abnormal
• Asynchronous stack Trace
• Promise Check
• Analysis

But because you are integrated with your Webstorm workspace, you can modify and edit your files while debugging. It's also running in a real NODE/V8 environment, not like that devtool . So it's more robust for most node. js applications.

Iron-node

A similarly Electron-based debugger is iron-node. iron-nodecontains a built-in command to recompile the native plugin, as well as a complex graphical interface to display your package.json and README.md .

Instead devtool , focus on the command line, Unix-style plumbing, and redirection and Electron/browser APIs as interesting use cases.

devtoolProvides a variety of features to behave more like node. JS (for example require.main , setTimeout and process.exit ), and covers internal require mechanisms as source maps, as well as improved error handling, breakpoint injection, and "browser" field solutions.

Node-inspector

You might also like Node-inspector, a tool that uses remote debugging instead of building on an Electron.

This means that your code will run in a real Node environment, without any window or any other Browser/electron APIs to contaminate the scope and cause problems with some modules. It has a strong support for large node. JS applications (that is, local plug-ins), and has more control over the developer tools instance (i.e. can inject breakpoints and support network requests).

However, because it has re-implemented a lot of debugging skills, it may feel slower, awkward, and more vulnerable to development than the latest version of Chrome developer tools. It often crashes and often leads to node. JS developers being very helpless.

devtoolThe goal is to get people who come from Chrome developer tools to feel more comfortable, and also to add features like Browser/electron APIs.

Debug node. js in the Chrome developer tools