[Poll/RFC] Remove the built-in debugger

[Ben Noordhuis]

The built-in debugger is a major pain to keep working and some
informal polling suggests that no one really uses it or is even aware
that it exists.

I'm toying with the idea of dropping it altogether and replacing it
with some hooks for projects like node-inspector and node-webkit-agent
because that's what everyone seems to be using anyway.

Before I go ahead, I would like to know whether there are people out
there that would be negatively affected by such a change.

If you are or if you disagree with the approach outlined above for
other reasons, now is the time to speak up! :-)

[Andrew Kelley]

I for one use the CLI debugger extensively. It would be missed. That being said, my mind is open to other possibilities.

[Denis Bardadym]

I would like to add, that while CLI debugger is official, after remove will rest only NOT official modules.
I can understand while you want to remove it, but without official tool, it is a bit scary =)

12 нояб. 2013 г., в 19:38, Ben Noordhuis <in...@bnoordhuis.nl> написал(а):

> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Paddy Byers]

Hi

Presumably this will kill the IntelliJ IDE (http://www.jetbrains.com/idea/features/nodejs.html) ?

I don't know how widely used it is, but it is the most effective debug setup I've used with node.

Thanks - Paddy

[Alex Kocharin]

> I would like to know whether there are people out there that would be negatively affected by such a change.

Yes.

There is no good alternative for built-in debugger right now. node-inspector and node-webkit agent are both web-based, they require to use chromium, hard to set up with remote servers, don't always work on unstable, etc., etc. Maybe something has changes over the last months, but I have rather negative experience using them before.

I suppose if you take it out of the core and publish as a separate module, this would work. But we really should have a simple debugger that works everywhere and anytime regardless of the environment. Which means command line debugger.

Why is it pain to support anyway? I just did 'git log _debugger.js', and there aren't much changes there. I know that readline changes break it sometimes, but it's not a big deal.

[Ben Noordhuis]

On Tue, Nov 12, 2013 at 4:52 PM, Paddy Byers <paddy...@gmail.com> wrote:
> Presumably this will kill the IntelliJ IDE
> (http://www.jetbrains.com/idea/features/nodejs.html) ?

I'm fairly sure it talks to V8 directly. As long as --debug-brk keeps
working, there should be no issue. Ditto for node-inspector and
friends.

[Ben Noordhuis]

On Tue, Nov 12, 2013 at 4:57 PM, Alex Kocharin <al...@equenext.com> wrote:
> Why is it pain to support anyway? I just did 'git log _debugger.js', and
> there aren't much changes there. I know that readline changes break it
> sometimes, but it's not a big deal.

Take a look at the changes to src/ and test/simple/. The time spent
on keeping the debugger's supporting infrastructure and test suite
working is in my perception disproportional to the number of people
that actually use it. It hampers new development and it even gets in
the way of bug fixes sometimes.

That's what prompted me to start this thread, actually: spending one
hour on some bug fixes, then spending the rest of the day trying to
work around debugger issues.

[Forrest L Norvell]

I have used the debugger for several hundred hours in the last year alone. It is an absolutely essential part of my day-to-day workflow. node-inspector is cumbersome and node-webkit-agent lacks the functionality I rely on.

I can't stress enough how necessary JavaScript source-level debugging is for me to be able to do my job.

F

[Fedor Indutny]

I have used it a lot recently too.

[Angel Java Lopez]

I never use that debugger.

console.log and TDD are my close friends ;-)

Angel "Java" Lopez

@ajlopez

[Paddy Byers]

Hi,

I'm fairly sure it talks to V8 directly.  As long as --debug-brk keeps
working, there should be no issue.  Ditto for node-inspector and
friends.

Yes it does talk V8 directly but it sounded as if perhaps you were planning to disable the option.

Thanks - Paddy 

[Andrey]

I use it every day and fall back to node-inspector only when I really need to walk stack a lot. At the same time, I think it should not be part of node core and exist as npm-installable script. (I'm big fan of "No" [1], but unfortunately other core functionality can't be removed without much pain today). I started to extract debugger to external module [2] some time ago to use it in my vim-based debugger [3] but realised that it's possible to reuse debugger client from core by just doing `require('_debugger')`.

My suggestion:

  - remove debugger when full feature complete clone exist in npm

  - make 'node debug' try to call this module if installed and print warning if not ("internal debugger has moved to npm. Please do 'npm install some-debugger-module-name'")

  - document protocol client library and debugger cli language. Make debugger client language not based on javascript (when you do "continue" in repl you executing "continue" property read handler). Fix broken functionality (up/down, set breakpoint is broken in debugger, I use "debugger" keyword or switch to node-inspector when I need to set breakpoint) - This would be much easier to do with external module than node core. (own release cycle, no need to sign contributor license agreement etc)

I can volunteer to do these steps if there is enough interest to move in that direction.

 

[1] http://vimeo.com/56402326

[2] https://github.com/sidorares/v8-debugger-protocol

[3] https://github.com/sidorares/node-vim-debugger

[Eldar]

Built-in debugger is the only debugger I used. Typically I just set a breakpoint and inspect some vars and that's all.

Things like node-inspector are not worth launching for such sort of things. 

вторник, 12 ноября 2013 г., 19:38:36 UTC+4 пользователь Ben Noordhuis написал:

[Ben Noordhuis]

Okay, so the outcome seems to be that there are a handful of users.
I'll keep the debugger around for a little longer but I'm going to
apply the following changes:

1. Update the stability level to '0 - Deprecated'. No bug reports or
pull requests accepted anymore, it is what it is.

2. Remove the tests. They're really flaky anyway.

3. Medium/long-term break out the debugger into a separate module.

Thanks for taking the time to reply everyone.

[Ben Noordhuis]

On Wed, Nov 13, 2013 at 1:20 AM, Andrey <andrey....@gmail.com> wrote:
> I use it every day and fall back to node-inspector only when I really need
> to walk stack a lot. At the same time, I think it should not be part of node
> core and exist as npm-installable script. (I'm big fan of "No" [1], but
> unfortunately other core functionality can't be removed without much pain
> today). I started to extract debugger to external module [2] some time ago
> to use it in my vim-based debugger [3] but realised that it's possible to
> reuse debugger client from core by just doing `require('_debugger')`.
>
> My suggestion:
> - remove debugger when full feature complete clone exist in npm

Agreed.

> - make 'node debug' try to call this module if installed and print warning
> if not ("internal debugger has moved to npm. Please do 'npm install
> some-debugger-module-name'")

Agreed on the 'print a warning' part, not so sure about the auto-loading part.

> - document protocol client library and debugger cli language.

It's documented here: http://code.google.com/p/v8/wiki/DebuggerProtocol

> Make debugger client language not based on javascript (when you do "continue" in
> repl you executing "continue" property read handler).

Don't know about this. If you're creating an external module, then
it's up to you, of course.

> Fix broken functionality (up/down, set breakpoint is broken in debugger, I use
> "debugger" keyword or switch to node-inspector when I need to set
> breakpoint)

That may be part V8 bug, see
https://code.google.com/p/v8/issues/detail?id=2981 (though in that
case node-inspector would likely be affected as well.)

[Andrey]

I meant client itself, not protocol, though they are very similar. Public api like client.reqScopes, client.reqEval, client.reqBacktace etc. A lot of project re-implement this functionality just because it's not documented. 

[Ben Noordhuis]

Oh, that. That's not public at all. Nothing in the module is.

[Ben Noordhuis]

The pull request for steps #1 and #2:

https://github.com/joyent/node/pull/6507

[Andrew Kelley]

So for those of us who exclusively use the built-in debugger, now that it is deprecated, what should we be using instead? I'm not aware of another CLI node debugger.

[Andrey]

You can use https://github.com/sidorares/node-cli-debugger

 I spend something like 30 minutes on it, so it's very alpha but looks like it works the same way as built in debugger. Please report bugs or inconsistencies with node's debugger.

Andrey

[Timothy J Fontaine]

A pull request is not the actual deprecation, there is still more conversation to be had on this topic.

--

[Andrey]

>   - make 'node debug' try to call this module if installed and print warning
> if not ("internal debugger has moved to npm. Please do 'npm install
> some-debugger-module-name'")

Agreed on the 'print a warning' part, not so sure about the auto-loading part.

It's easy to switch from "node debug" to say "node-debug" but it's also used in other scripts - what about "mocha debug" or "coffee --node.js debug"? 

[Floby]

I haven't had the need for a debugger in probably years.

I recently used node-inspector and it worked reasonably well for me (breaking on `debugger` and inspect stack vars). Still surprised there's no `node-inspector myScript.js` already working though.

I mostly use hardcore TDD nowadays and it has lifted the need for a debugger for most cases. The rest of the time is testing and logging.

[Andrey Sidorov]

I created simple script to wrap all the preparation steps for to start
node-inspector: https://github.com/sidorares/ni

npm install -g ni
ni myScript.js

> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---

> You received this message because you are subscribed to a topic in the
> Google Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/aari58_A6Y8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[José F. Romaniello]

I use 'nodev script.js' (or nodev --debug-brk)

https://npmjs.org/package/nodev

--

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---

You received this message because you are subscribed to the Google Groups "nodejs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.

[Ben Noordhuis]

After some more discussion, we've decided to keep the debugger around
for a little longer. The tests may still end up getting scrapped
unless someone gets around to rewriting them.

[Andrey Sidorov]

So what would be debugger status? Do you encourage users to report
errors / send PR with fixes or it stays frozen until fully deprecated?

> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---

> You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/aari58_A6Y8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

[Ben Noordhuis]

On Wed, Nov 20, 2013 at 12:35 AM, Andrey Sidorov
<andrey....@gmail.com> wrote:
> So what would be debugger status? Do you encourage users to report
> errors / send PR with fixes or it stays frozen until fully deprecated?

"Encourage" is a strong word but bite-sized pull requests are welcome.
Bug reports may or may not see much action.

[tjholowaychuk]

I prefer the CLI big time when it works :D