How to debug what file in a directory breaks Atom


#1

So I have a nasty bug in Atom. Issue filed already

But I’m eager to resolve this as soon as possible. (Because I can’t even work on this project with Atom at the moment)
What happens is that there is a file somewhere in the directory that is causing the error:

Uncaught (in promise) TypeError: Cannot read property 'length' of undefined
at Project.module.exports.Project.setPaths (/Applications/Atom.app/Contents/Resources/app/src/project.js:271:44)
at /Applications/Atom.app/Contents/Resources/app/src/project.js:143:30

None of those files exist on disk otherwise I’d open them in an editor and sprinkle a bunch of console.log to try to figure out what’s causing the error and then perhaps delete or fix that file in my directory.
There is no file called /Applications/Atom.app/Contents/Resources/app/src/project.js on disk. But I’d love to find out what’s happening on like 271 and 143 in this file. And also, how do I change that file (e.g. sprinkling of console.log) and rerun?


#2

Hey peterbe,

Thanks for asking. The problem is that all the code gets included in a snapshot by default. You can open a window in development mode from the command palette with Window: Open Dev which will allow you to set breakpoints in the dev tools, but the files are still archived.

The best way to debug issues like this is probably to clone the repository to ~/github/atom (or whereever you want and set the ATOM_DEV_RESOURCE_PATH environment variable to that location. Then run script/bootstrap in that directory to install all of the dependencies. Once you do that, opening a dev mode window will actually load source from the repository instead of from within the application bundle, which will let you modify stuff.

Thanks for taking an interest in fighting this bug. Looks like this is a pretty late reply but hope it helps.


#3

As mentioned here https://github.com/atom/atom/issues/15992#issuecomment-342818128 the “solution” is to run atom --clear-window-state . and now I can open Atom again.

That’s good news but doesn’t really answer the question of this discussion. However, @nathansobo’s response will be a good to have there. I have not tested it.