Uncaught Error: spawn ENOENT about atom-grunt-runner

[blvz]

@tvooo Take a look at this comment.

[JaKXz]

I'm seeing the same issue... I tried to set process.env.PATH like the comment says but no luck. I'm not having any issues with Sublime Text though.

[blvz]

@JaKXz Try to compare the process.env.PATH when launching Atom from the command line with the one when launching from the icon.

[joseym]

6 month old (feature breaking) bug with no solution or even acknowledgment from the creator?

I'm assuming this is a dead project and am removing this potentially super-useful package from my installation...

Sad.

[joseym]

It definitely lacks the same "wow" potential as being able to select between grunt tasks but noseglid/atom-build is a working solution for anyone else experiencing these problems with grunt-runner and have yet to find or be presented with a solution.

[maxkorp]

So this seems to be related to a few things. First, if you're starting atom from the command line, it gets path correct, but in mac at least, starting it spotlight or mission control sets it somewhere else. Adding /usr/local/bin/ (the default path for when you do npm install -g grunt-cli) to the path in the grunt-runner settings seems to get it to run grunt (for me). However, its running the wrong gruntfile. Trying to figure out which, I suspect its trying to run the grunt file for grunt-cli, but i'm not sure.

[maxkorp]

Interesting, that was a typo in my gruntfile (I think i hit a key when i thought i had my terminal focused). Updating the path to grunt cli in the plugin settings worked, as well as loading atom in the project directory from the command line. Looking in to setting up the paths for launching things from spotlight/mission control. I might modify the readme a bit and submit a PR.

[maxkorp]

Also note that reloading the application once youve opened your project (ctrl+cmd+alt+L) will fix issues where its looking in the wrong directory.

[jjgonecrypto]

I've found the same as @maxkorp - refuses to work when loading through Spotlight unless you reload it as mentioned. In both cases setting the path in InitConfig is required (/usr/local/bin for me). It seems that it has to do with Atom loading the project on startup, vs being told to open it via cmd+O which you have to do when opening via Spotlight.

[maxkorp]

Correct. I have a few changes locally that fix this, but I haven't gotten to clean them up yet so I'm not comfortable filing a pull request (The ones in my commits mentioned above dont work at all, but i took a fresh stab at it).

I'll try to get that this weekend. I basically default to include /usr/local/bin, as well as reinitializing when the project changes (theres an event for that). As it stands, the functionality would just keep grunting project a if you opened from project a in the terminal, but then used another plugin to change to project b. Changes fix that as well.

[kokarn]

Ah, this would be very welcome!
I've encountered the same error simply by first having an empty tab and then opening a project.

[maxkorp]

Yeah so the issue is that upon initialization of the package, it grabs the current project directory and caches it. It also tries to load the grunt tasks for the project, and cache those. When you load up via finder or spotlight, the project directory is undefined. Simply reloading that info on the project changed event or whatever its called takes care of it. Its a simple enough change, my coffeescript is just rougher than all get out.

[kokarn]

@maxkorp Is this still an issue?

[maxkorp]

I don't know, unfortunately. I haven't been using grunt in a real way for 6+ months now, as I have everything automated.

[kokarn]

Hmm, i'll close this for now then. If somebody else reports it, i'll reopen. Thanks for the quick response!

[maxkorp]

👍 No problemo!