Debugging my package?


I don’t have the JavaScript debugging approach for extensions figured out at all. I can get my source open in the debugger (most of the time) but can figure out how to get execution to stop at a breakpoint after I set one.

Are there instructions somewhere for how to use the Dev Tools JavaScript debugger for working within Atom’s extensions?


Have you used it before in a web page? It runs identically here and there. Google for chrome dev inspector help.

One tip: Set a breakpoint and then reload using ctrl-shift-r which is exactly the same as done on a web page.


I have used the Dev Tools debugger before on “standard” websites.

If I reload after setting the breakpoint, Atom doesn’t load my package back until I’ve executed a command from it.


I don’t see why that matters but you can temporarily remove the activationCommands from your package.json to have it load immediately.


Now I didn’t know that! Clever idea. I’m going to mess with that…


But no, opening the Dev Tools and executing a command still does not stop a the breakpoint. The file is open in Dev Tools, the breakpoint is marked, but it doesn’t halt execution. :frowning:


I would bet dollars to donuts the code isn’t really getting to that breakpoint. My experience is that the inspector is very reliable for that.

Put in a console.log debug message at that point.


My suspicion is that you don’t have the right file open. You’re either opening the file in your source directory, but not executing that one. Or you’re opening the file in the packages directory, but executing the one from your source directory.


That’s plausible. So I back-tracked.

Now I have my package files in a folder that is sym-linked into ~/.atom/packages. So there should be only one .js file.

Now I:
Opened Atom in normal mode
Selected the “open here” command from the contextual menu to load the file
The command executed as normal
Opened the Dev Tools to sources and cmd-P searched for and open my .js file
Set a break point in the “open here” command
Selected the “open here” command from the contextual menu
The debugger stopped on the debugger statement and jumped over the breakpoint.

It looked like this:

When I continued, the command completed and the editor was frozen.

This is weird.


I don’t know which piece of what I’ve done got the debugger to stop at breakpoints again (it still won’t stop at debugger; statements), but it does.

With Atom 1.0.0, I disabled all my packages except the one I wanted to debug and the Package Cop. The debugger stopped at breakpoints. So I enabled all my extensions, and it still stopped at breakpoints. Hmmm. Well, OK then.

But it disrupts the editor pane(s) when the debugger returns control to Atom.

Again using Package Cop I disabled all the packages except Package Cop and the package I’m debugging (that sure speeds up the initial Atom launch!). The debugger still stops at breakpoints. But when I continue running, control returns to Atom and the editor pane is unresponsive. No cursor, no scrolling, no response to clicks - nothing. The tree-view pane works as always.

Reloading Atom puts things right again.

What could that be from?


I find this combination of symptoms hard to comprehend. It’s not like they’re separate processes. If one is working, so should the other.

Do you have a set of steps that consistently reproduces this issue in Safe Mode?


I suspect so. But it’s hard to find something to set a breakpoint in from core. Could you suggest a file and line to try? I only have the two packages active beyond Atom’s base set.


Any tips on where to set a breakpoint after I atom --safe?

Finding files in the debugger is such a pain because there’s nothing really in the sources file view to find and open. The search function returns a huge list of files matching scattered, rather than contiguous letters. It’s messy.


How about the first line of a deactivate function for a built-in package like tabs? Then you can disable the package through the Settings View?

To be honest, I rarely rely on the debugger. I write tests for my code and use those as essentially permanently-stored, repeatable debugging sessions.