Jump to content

Make use of NodeJS environment

Recommended Posts

Hello everyone,


I like NodeJS. It's awesome on my server, and it's pretty sleek on my computer with Alfred (I currently have a workflow that lets me browse any music/movie/show torrent with metadata from rottentomatoes or last.fm and streams it right to VLC and saves the cached files if i want, so much better than popcorn time if you ask me).



But here's the problem: more and more libraries being released are based on NodeJS and they all start the same way:

#!/usr/bin/env node

So they do awesome stuff as long as you have node installed on your computer. And Alfred can control all that if you don't mind it popping up a terminal.



But I want to release my favorite workflows to the public. So I'd rather go with a "Run Script" with /bin/bash so the terminal doesn't pop up. How do you use NodeJS in such case? Do you include it or ask the user to install it on his own? And in both cases, how do you get to that /bin/env node





As an example, here is where i'm at:


I'm using this "Terminal Command" action (i guess you can make it a one-liner but i'm not so good at shell scripting):

var=( $var )
peerflix "magnet:?xt=urn:btih:$var" -qvr -f ~/Movies/

where $var ends up being  the ID for the magnet link



But using the almost same thing as a "Run Script" (so the terminal doesn't have to pop up, and long term, so i can include nodejs with my workflow and have a worry-free user) with /bin/bash, as such:

var=( $var )
./peerflix "magnet:?xt=urn:btih:$var" -qvr -f ~/Movies/

I invariably get:

Code 127: env: node: No such file or directory


Any advice greatly appreciated!

Thank you all

Edited by Florian
Link to comment

Regarding including node with your workflow, there’s a discussion brewing that addresses some important points on the issue.

As for your other question, the problem is Alfred does not read your environment, which is why #!/usr/bin/env node does not work. You have to tell Alfred how to get to node, just like you likely do in your shell’s startup files. You can do it in a variety of ways, but the simpler and most effective are to either set the PATH variable at the top of the script to include the path to where node is likely installed (something like export PATH=$PATH:/usr/local/bin), which should take care of your env concern; or, when calling node, you set it’s full path directly (i.e., no #!/usr/bin/env node, but instead #!/usr/local/bin/node or whatever its location may be).

Naturally, in both these cases you have to make sure the user has it installed to the same location as you; or in the case including it, just set the path to that relative location.

Link to comment

Perfect. Silly me :) That's a clean workflow now. But the frowned upon kind :)

They're not exactly frowned upon (though I don't think node will ever be a "blessed" workflow platform), but you're likely to end up with a load of support requests because (1) node isn't installed on OS X by default, (2) if it is installed, it might not be installed where your workflow expects it, and (3) it might be an incompatible version.

Different OS X releases have different versions of Ruby/Python etc. installed, but at least devs can be sure which version is on which OS X release and say, "Mountain Lion and later" or whatever.

I'd always be leery of distributing a workflow that depends on a non-standard language because it's very likely that a user will ask you why it's not working, and you tell them to upgrade node or whatever, which then breaks something else that depended on that version…

Ultimately, it boils down to how important it is that your workflow works for everyone and how willing you are to tell people "tough, it won't work for you".

Edited by deanishe
Link to comment

If you want to make this more "universal," then you could do it one of three ways:


(1) Create an installation script that would install node on the user's computer (telling them a million times what you're doing). Include a way to uninstall everything.

(2) Create a workflow that installs and manages node in a separate directory, not in a system path. The workflow would give them easy access to it. Then, you could make use of external triggers by checking to see if node is installed on the system; if not, check to see if node is installed in that new path; if not, then throw up a pop-up for the user, asking them to download this "node install" workflow before using your other node workflows.

(3) Integrate node into the dependency bundler (see forum thread; see GH page) and let that do all the heavy lifting for you.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...