Debugging experience

[thoughtsunificator]

Start the debugging client as soon as a debugger statement is met.

Information about the debugging protocols should be abstracted, which for the most part is not the case since we need to know that there is a server and a client, why should the developer care? How should they be abstracted? Well we can start with the fact we currently need to ask twice for the debugger to start, one with the debugger statement and two by using the debug command and in some cases you even have to add the inspect command to the equation, that's a hell lot more than just running your program and expecting the runtime to do what you asked by using the debugger statement which is... Start the debugger.

I propose that either a new env is added or we use NODE_ENV which seems like a pretty good use of it. When set, ANY script shall be debuggable either using the internal debugger client (CLI) or simply by providing the server depending on the execution context.

If that's the case, then:

• deno run foo.js
• deno task foo
• deno test

All of these will work as is and be easily debuggable with no additional effort required (other than using the debugger statement) on the developer part.

[marvinhagemeister]

FYI: Both Deno and Node are built around V8 JS engine which is why the debugger integration is the same. It's provided by V8, not by Deno or Node. So there is no copying anywhere because both projects directly use the one provided by V8.

[marvinhagemeister]

It seems like you have a well defined vision in your head of how you'd like the debugger to work. Have you considered making a PR?

[thoughtsunificator]

Well... Maybe I would if anyone could try and explain to me why it was done that way :)

[bartlomieju]

Well, maybe I would if anyone could explain to me why it was done that way.

Because connecting a debugger client requires spawning a WebSocket server, which is not free to create and binds to a certain port (127.0.0.1:9229 by default). Most users don't want a WS server being spawned in their production environment and that's why it's not done unless you provide a flag to inform you'd like to connect a debugger.

[thoughtsunificator]

Then how about an env instead? Which would, at the very least, fix my second issue (and the issue you mentioned).
How about NODE_ENV for example, which already exists by the way.

The bind thing is a non-issue, as Deno is already aware that both the client and the server originates from a single command: deno run foo.js in a NODE_ENV that is for sure not set to production.

I mean, that's the whole point of it, if we're trying to accommodate our DX to production needs we're not going to go far.

I propose that either a new env is added or we use NODE_ENV which seems like a pretty good use of it. When set, ANY script shall be debuggable either using the internal debugger client (CLI) or simply by providing the server, depending on the execution context.

[thoughtsunificator]

I edited both the title and the content to something that is a bit more on point.