Deno: support chome devtools

[ry]

V8 has extensive debugging abilities built-in.
This is what allows Node to connect to Chrome inspector for debugging.

The behavior of node --inspect --debug-brk script.ts is usually the behavior people want - which is start V8Inspector and break on line 1 of the main script. In deno, I'd like to shorten this to deno script.ts --debug.

This is a large feature which will probably require several passes. The core binding to V8Inspector should be done in libdeno.

[sh7dm]

We can also make a VS Code extension based on Chrome debugger to debug with Deno easily!

[oldrich-s]

I would just add that I use both debug and debug-brk in Node.js.

Often I start an application with debug flag to be later on able to easily hook into it if necessary.

[Fenzland]

Maybe console.log should not print anything without --debug. That's designed to log things on devtool rather than user view. For stdout outputting, we have Deno.stdout.write already.

[kitsonk]

There is a lot of code that expects console.log() to write to stdout. Changing that behaviour would surprise a lot of people. I would be 👎 for changing that.

[Fenzland]

@kitsonk Thank you for your attentions. Break changes are not welcome. But it's not too late to discuss ideas like this until 1.0 is released. One goal of deno is 'not explicitly compatible with Node', but make better designs. I think make clear between debugging and stdout is helpful for this.

[kitsonk]

I still don't think it is a better design.

[hayd]

console.log not printing to stdout is a separate issue. This issue is about debugging with V8Inspector .

[jimmont]

unless using a redirect mechanism, expecting clear relationships:

console.log == stdout
console.error == stderr
console.warn == stderr

so that with a way to redirect (and it's not because Nodejs has this)

[NamPNQ]

@Fenzland Please create another issue or just start discuss in gitter

[jpike88]

Is it possible to maintain backwards compatibility with the existing vscode extension?

[NamPNQ]

@jpike88 what the vscode extension you mention?

[jpike88]

https://github.com/microsoft/vscode-node-debug

[jpike88]

A Deno debug session is basically a node debug session with TS source maps built in. Why not just directly route through to the v8 process, and inform it correctly with virtual/inline source maps or something?

[mtharrison]

The vscode debugger is just another frontend (like devtools), we need to write the integration with Deno and the backend V8. Once that's done, you should be able to use vscode debugger too.

[Extarys]

Is there a Firefox extension that would allow/emulate Google devtools using deno --debug with it? I don't use Google products :O

[jpike88]

Technically v8 isn’t a google product in the sense you’re probably thinking, only Chrome is. You won’t have any data sent or collected by google when using something like demo (or Nodejs, which also uses v8).

[Extarys]

I was talking more about being "forced" of using a Chrome-based browser to debug a Deno app. But if we can debug directly in VS Code... then I'm fine.

[kitsonk]

Which of course VSCode is an Electron App which is based on Chromium/Node.js and runs V8. 🤷‍♂

[Extarys]

I know :cry: But I still refuse to use any chrome-based browsers. Technically, VSCode is not a browser.... (well... anyway :laughing: )

[kitsonk]

Yeah, I guess you shouldn't then ever look under the help menu in VSCode.

[jpike88]

Just to be pedantic:

chrome-based

You mean chromium-based. Google Chrome is chromium + Google's services

[Extarys]

@jpike88 Yes. Still, Chromium is developed by Google, mostly.

@kitsonk I do know what an electron app is :wink: ...
I still refuse to browse the web using chromium based browsers.

[flying-sheep]

We’re talking about the v8 inspector protocol here right?

VS Code and Chrome/Chromium devtools support this, anything else?

[flovilmart]

Is it actively worked on by s/o? Would be interested to chip in.

[brandonkal]

If anyone needs an interim solution, here is how I am debugging Deno programs in Node right now: https://github.com/brandonkal/deno-lib/commit/37b44f1e05e48ebf620fcd953ddfbc5689544cbb

[quantuminformation]

thanks @brandonkal chrome debugging is defo what I need.

[Soremwar]

Hey guys, something caught up my attention while reading about Node's debugging environment.

From Node's official documentation

How much of Deno's security system is applied in behalf of the debugger? Should we specify access flags for the debugger as well?

[kitsonk]

The debugger would not be able to elevate the Deno permissions, as all access is through the Rust ops. You can still run arbitrary code over the debug port, but only with the permissions that have been given to that workload. Leaving a debug port open in production is still a "bad" idea.

[bnoordhuis]

Is anyone actively working on this, e.g., @bartlomieju? I have some spare cycles next week (if I my kids don't get sick again ^^) and I have a pretty good idea on how to attack this.

[bartlomieju]

@bnoordhuis currently @ry is working on devtools

[ozanmuyes]

Thank you for deno, I should say that first. Any news on this issue?

[brandonkal]

@ozanmuyes The issue will be closed when there is news.

[ry]

It's on my queue, I will resume work soon.

[ozanmuyes]

@ry Awesome, thanks. Sorry for the question if its improper on these "pandemic" days, I just realize. Even though I wasn't expected such a quick response, impressed.

[KSXGitHub]

Leaving a debug port open in production is still a "bad" idea.

It is convenient however. Imagine being able to fix some bugs temporarily without user waiting for new version to be developed and deployed. If we can set password to access remote debugger, would it still be a bad idea?

[kitsonk]

If we can set password to access remote debugger, would it still be a bad idea?

Distributing code with backdoors... 😱

[KSXGitHub]

Distributing code with backdoors...

I was talking about web server, not code that runs on user's machine.

[brandonkal]

I was talking about web server, not code that runs on user's machine.

You are describing embedding a backdoor in a production web server. That's something you just don't do. How would you like it being in a checkout flow knowing a developer or bad actor with a password can monitor and alter your request and response? That's a very very bad idea.

[jpike88]

Simple, just put it behind a flag. If you want the debug port open, set a flag. It’s how node works.

[brandonkal]

That is what was proposed here with the--debug flag. It would listen on the local interface only.

[Soremwar]

@jpike88 I've done that. In the the two month time span that backdoor was in production (open to me so I could monitor a highly experimental feature) I was so close to have a mental breakdown out of stress.

Literally, if they ever noticed about that, I would have lost my job in the blink of an eye, and maybe even losing my reputation in the process.

Test your software, don't deliver unfinished or experimental products. And for love of god don't leave backdoors open.

[kitsonk]

I was talking about web server, not code that runs on user's machine.

There are secure patterns for production observability that do not require leaving backdoors running on your production servers.

[vegerot]

I would just add that I use both debug and debug-brk in Node.js.

Often I start an application with debug flag to be later on able to easily hook into it if necessary.

So in that case the question is should the default behavior be to break at start, and add another flag to not break, or the other way around like Node does it