Does the new Workflow make it easier to use node.js?

[ferik]

Hi,

 

I'd like to control my home automation with Alfred. Ideally I would do this in node.js. It used to be fairly complex to do so with node since it wasn't a first class citizen. Is it any easier with Alfred 3?

 

Regards,

 

Erik

[deanishe]

I'm not sure what you mean by "wasn't a first class citizen". On OS X?

 

Node's status is the same as it ever was with regard to Alfred 3. Alfred doesn't care what language/platform you use for your workflow, as long as it understands UTF-8.

[sindresorhus]

The hard part about using Node.js with Alfred is that the user's $PATH is not defined, so the `node` command is by default not available. I made a helper library, Alfy, that solves this and adds many useful utility methods.

[deanishe]

The hard part about using Node.js with Alfred is that the user's $PATH is not defined

Yes it is. It's /bin:/usr/bin

If you want the PATH defined in your shell, then you need to start Alfred from a shell. Same goes for every program on OS X.

so the `node` command is by default not available.

Of course it's not available "by default". How could it be when it isn't even part of OS X?

[sindresorhus]

That's not the user's custom $PATH. That's the default $PATH defined by macOS. And nobody starts Alfred from the command-line.

 

I meant that when Node.js is installed the `node` binary is not available by default, since it's installed in `/usr/local/bin`, which is by default not in the $PATH in Alfred. Alfy works around this by getting the user's $PATH, so running `node` in Alfred just works when Node.js is installed. This is nice as otherwise you would have to instruct users to manually set the location of the `node` binary.

[deanishe]

That's not the user's custom $PATH. That's the default $PATH defined by macOS.

Wrong and sort of right. It is the user's PATH. It just happens to be the same as the default PATH because you haven't actually configured it. A shell is no different. If you don't configure your own PATH, you get the system default.

Your user session is bootstrapped via launchd, not a shell. So obviously it inherits your launchd environment, not your shell one.

If you want to change PATH in your real user environment (i.e. the launchd one) as opposed to your shell environment, use launchctl setenv PATH /usr/local/bin:$PATH (but you have to run it at the right time).

That will also be inherited by any shells you run in Terminal/iTerm (because it's inherited by the applications).

 

And nobody starts Alfred from the command-line.

Indeed. So how is Alfred (or any other application) supposed to know about your shell environment when it isn't started from your shell?

This is absolutely standard UNIX behaviour. cron and init.d on Linux don't use your environment, either, because they aren't run from your shell.

The bottom line is that your OS X apps have the default empty environment because you haven't configured the environment at all.

[sindresorhus]

I'm aware of all this. Was just pointing out that Alfy makes it easier to create workflows using Node.js as it works around that limitation.

[deanishe]

since it's installed in `/usr/local/bin`, which is by default not in the $PATH in Alfred. Alfy works around this by getting the user's $PATH, so running `node` in Alfred just works when Node.js is installed. This is nice as otherwise you would have to instruct users to manually set the location of the `node` binary.

 

Meh. That's a cool trick, but messing with PATH can have unintended consequences. Sure, it means you can just use node instead of /usr/local/bin/node, but if a user (or the developer) has installed Homebrew packages, like GNU coreutils or cURL, which provide newer or different versions of default programs, weird things can happen.

[deanishe]

I'm aware of all this.

Right. Sorry. You did say the opposite (PATH is undefined; it's not the user's PATH) in your earlier posts.

Was just pointing out that Alfy makes it easier to create workflows using Node.js as it works around that limitation.

The library looks good. Is it production ready? Is there a forum thread for it?

If you have or would like to write a description of it, I can add it to the Workflow Libraries and Helpers sticky for you (if you want).

There are no JS/node libraries in there at the moment. It'd be a great addition, as JS is a popular language with younger developers.