debugger: deprecate built-in debugger #6507

Closed
wants to merge 1 commit into
from

Projects

None yet

8 participants

@bnoordhuis
Owner

Reduce the maintenance burden a little by deprecating the built-in
debugger.

Polls in the IRC channel and on the mailing list suggest that not many
people use the debugger or even know it exists. The few that do are
generally happy to see it get moved into a separate npm module.

This commit takes the first step my deprecating the debugger and
removing its tests. The tests were very flaky anyway, they won't
be missed.

Suggested reviewers: @indutny @tjfontaine @trevnorris - there's not much to review, it's mostly removal.

@bnoordhuis bnoordhuis debugger: deprecate built-in debugger
Reduce the maintenance burden a little by deprecating the built-in
debugger.

Polls in the IRC channel and on the mailing list suggest that not many
people use the debugger or even know it exists.  The few that do are
generally happy to see it get moved into a separate npm module.

This commit takes the first step my deprecating the debugger and
removing its tests.  The tests were very flaky anyway, they won't
be missed.
37dfeac
Owner
indutny commented Nov 13, 2013

Its sad to see it, but LGTM. We should move it to user-land!

+1 and a LGTM

Do the necessary hooks exist so this can be built in userland?

luk- commented Nov 14, 2013

I know the decision is already made and it's probably for the better, but I'm going to be the person to mention that IRC & mailing list polls will only get you a certain kind of feedback. I have multiple colleagues at Yahoo who rely on the debugger and we were hoping to add more functionality to it, noted in #6368. A lot of these developers are so focused on building software that they don't idle in the node.js IRC channel or keep hourly tabs on the mailing list.

I'm aware that deprecation doesn't mean it's being removed from core just yet, but I hope before it is, the hooks can provide enough utility to build something with on-parity base functionality. Maybe that's possible already. If you're looking for feedback on these hooks both @davglass and myself can be points of contact, and we're very interested in being in the loop on the subject.

As much as I'm not a fan of the repl in node in general (debugger or otherwise), I'm not yet convinced we should deprecate the debugger repl outright.

At the very least, I would like to take yet another pass at rewriting the tests to something less magical which may require some of the very hooks in question.

Having better/saner hooks for enabling/disabling a debugger should absolutely be explored as is our custom.

Also, encouraging and helping design a replacement that can be fostered in module space would be key before any potential removal. Node would not be so drastic as to remove the debugger (or any feature) without having a migration path for consumers. We're too late in the game to make such hasty moves.

@luk- don't worry, I think we'll be soliciting more information.

I would happily trade the current core tests and the pain of transitioning the current CLI debugger to an npm package for a well-documented, stable debugger interface that builds on the V8 debugger protocol and adds support for e.g. stepping through asynchronous calls. I am also happy to contribute time to replacing the current flaky tests with something more maintainable and robust.

I have concerns about this PR, though, because the tests for the debugging interface are already pretty minimal / the coverage isn't great, and any replacement for the current debugger REPL is going to need something to build upon. Also, I'd prefer to see a stable npm build of the debugger followed by deprecation and removal rather than the current proposal. Some of us need a stable way to step through JavaScript source that's quick to start and available from the shell, and deprecating it without a replacement being available is a pretty poor developer experience.

@tjfontaine You know I'm a fan for Node having more hooks for users to build their own functionality and less core feature implementation. Though I'm not very familiar with the debugger or repl. Let's have a discussion about what hooks are necessary for users to implement the same in user-land.

@trevnorris having the appropriate sane and supportable hooks is going to happen. I am reluctant to remove something we have already shipped and people depend on, even if the first step is only deprecation.

@tjfontaine ok, then let's get started on creating those hooks! :)

Owner

having the appropriate sane and supportable hooks is going to happen

We already have the hooks and they're not going away. Modules like node-inspector only need --debug/--debug-brk and optionally the ability to start the debugger with a SIGUSR1 signal.

This PR only deals with the debugger client (the REPL.) Truth be told, I don't really have a strong opinion on whether or not it should go. If it's controversial, then we'll just leave it in.

The thing is that it doesn't seem to have many users (but see below), doesn't get much love from us maintainers and the test suite's coverage and reliability is terrible.

That's why I'm proposing to deprecate it in core and move it into a module. It has a better chance of improving that way than when every pull request has to go through one of us.

I know the decision is already made and it's probably for the better, but I'm going to be the person to mention that IRC & mailing list polls will only get you a certain kind of feedback.

That's true but what can you do? It's imperfect but I think some conclusions can be drawn from the results. If many of the "in-crowd" don't even know that the debugger exists (let alone use it), then it's probably fair to extrapolate that to the broader user base.

Member
rlidwka commented Nov 16, 2013

Dumb question: what would it take to make gdb work with node/javascript?

Owner

You get rudimentary gdb support when you configure with ./configure --gdb (requires a gdb with gdb jit support).

It makes JS function names show up in stack traces and (in theory) makes it possible to place breakpoints on JS functions. It might be possible to make gdb decode function arguments as well but I don't think it does right now.

Another option is to extend gdb through its python API. V8 has a basic script for that but it was a little flaky last time I tested it and, well, it's really basic - there's a lot more you can do.

Owner

Okay, after some more discussion we've decided to keep the debugger for now. We still may end up ditching the tests unless someone gets around to rewriting them and make them not fail every 1 out of 2 runs.

@bnoordhuis bnoordhuis closed this Nov 19, 2013
luk- commented Nov 19, 2013

That's true but what can you do? It's imperfect but I think some conclusions can be drawn from the results. If many of the "in-crowd" don't even know that the debugger exists (let alone use it), then it's probably fair to extrapolate that to the broader user base.

Sorry for the late reply, I didn't notice the email notification.

I think there's some truth to this but it's not nearly as accurate a depiction when proportionally scaled up.

Consider common arguments that take place on the mailing list: promises vs callbacks, small modules vs large frameworks, testing libraries, preferred control flow aggregation libraries, ES6 is ruining the world, etc, etc, etc.

To an extent, conversations like these will take place internally at large companies in person and on internal mailing lists, sure. The key difference is that while these discussions and mailing list threads are often a runaway train on the node mailing list, their place on internal discussions at companies is a lot more focused, between skilled and experienced engineers who want to solve a problem and get their work done, not argue all day. These conversations tend to end pretty quickly with objective rationality. The official node mailing list is a mainly open discussion forum where participants of all backgrounds and skill levels with various amounts of free time can chime in. That's not a bad thing at all, but it means that it takes more effort to determine how objective and fact-based an argument tends to be.

The point I'm trying to make is that values expressed and not expressed on the official mailing list are a good representative of the people who participate actively in public mailing lists. A colleague of mine today at a daily standup expressed concern over debugger, because it's an indispensable tool for him. Sure, maybe it would help in cases like this if he were more active on the mailing list, but he's not. He's busy spending his work hours writing software that powers node applications at Yahoo, and there are a lot of people like him who dedicate their time to writing software instead of deliberating in public forums. I work with a lot of people like this. I would love to see them participate more in discussions and try to encourage it as much as possible, but "what can you do," right?

#Node.js on IRC is also an even worse crowd to poll for something like this, since most of the discussion there is newcomers asking basic node or javascript questions. Seriously, just look at the logs.

I have a lot of confidence in what the core team does with the project and after talking about debugger more on an individual level, it sounds like this is the right way to go. I know it's not just getting pulled out completely, and there are hooks on the roadmap. If it even comes down to those of us who work on node stuff at Yahoo giving feedback and helping out, I don't doubt we can do that.

Finally, I hate writing conclusions to unnecessarily long replies, so I hope this is good enough closure if I end this sentence without proper punctuation

VRMink commented Nov 20, 2013

I am one of those developers who don't often participate in the public debate, and I am also one who spends more time in repl than anywhere else. I would personally regret to see it go.

Node has such a basic set of tools for debugging that if you take "debugger" out of core without replacing it with something else, I believe many newcomers will leave because of this lack of tools.

In my opinion core should consist of all of the tools you need to build a basic application, because many node users are not very well informed about the user land packages available, so removing it from core would remove it from their experience of Node.

+1 for building a better replacement first. GDB support sounds like a great idea.

@bajtos bajtos referenced this pull request in node-inspector/node-inspector Mar 21, 2014
Closed

debugger.js restructured #331

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment