3 ms·
I would say it also lowers the barrier to entry. Previously, you had to add a `debugger;`, visit "chrome://inspect/" in the browser, click "Open dedicated DevT
by alangpierce 8y ago
I would say it also lowers the barrier to entry.
Previously, you had to add a `debugger;`, visit "chrome://inspect/" in the browser, click "Open dedicated DevTools for Node", and leave it open while running node (mocha tests, in my team's case) from the CLI with --inspect. None of that is hard, and certainly it's much easier than previous alternatives, but it's still enough that it needs instructions. I got it set up for my team and made our test script print out those instructions, but even so, I think most developers viewed it as more of an "advanced" mode for when a test issue is really hard to track down.
With this new way, you run the test in debug mode and it pops up a window with everything set up already, no need for instructions. I'm hoping it'll make debugging easy/welcoming enough that more people will use a debugger as their default way to work on code.
- city41 8y ago--inspect-brk will start the node process then immediately break. It looks like ndb supports inspect-brk too.
- alangpierce 8y agoAt least in my situation, with no additional configuration, --inspect-brk works, but when it's paused at the start, I can't navigate to any of my files to set breakpoints, so the most straightforward way to set a breakpoint is a `debugger;` statement in the code. I guess that's one of the things that works better in ndb: "You can place breakpoints before the modules are required".
- city41 8y agoIt looks like ndb solves that problem: "You can place breakpoints before the modules are required."
- kabes 8y agoI don't have to do any of that. I start with --inspect-brk, I open chrome devtools and click the nodejs icon that's automatically added.