Node JS in a virtual environment?

[Sachinthya Wagaarachchi]

I am starting to learn Node and MEANJS at the same time, and want to have a development folder that is independent. I don't know how to go about it... I have used Mongo and AngulaJS with Pyramid. Here's what I think I want. (Using linux mint, btw)

+ I want an independent environment that doesn't change the system. For instance, when I develop using Pyramid, I use a python virtual environment which I can basically delete without effecting the system. I don't know if Node has something like that.

+ If that's not possible, what's the best way to have sort of two independent decoupled projects on the same system but with different (and maybe conflicting) dependancies?

+ I don't want a virtual machine, just something comparable to venv in python (http://docs.python-guide.org/en/latest/dev/virtualenvs/)

I don't have anything conflicting, but just like the idea of being able to delete the folder and start from scratch without changing the system at all...

Thanks :)
Sachi

[Aria Stewart]

> On 12 Dec 2014, at 18:49, Sachinthya Wagaarachchi <xco...@gmail.com> wrote:
>
> I am starting to learn Node and MEANJS at the same time, and want to have a development folder that is independent. I don't know how to go about it... I have used Mongo and AngulaJS with Pyramid. Here's what I think I want. (Using linux mint, btw)
>
> + I want an independent environment that doesn't change the system. For instance, when I develop using Pyramid, I use a python virtual environment which I can basically delete without effecting the system. I don't know if Node has something like that.

TL;DR: That's the way node works and always has.

> + If that's not possible, what's the best way to have sort of two independent decoupled projects on the same system but with different (and maybe conflicting) dependancies?
>
> + I don't want a virtual machine, just something comparable to venv in python (http://docs.python-guide.org/en/latest/dev/virtualenvs/)
>
> I don't have anything conflicting, but just like the idea of being able to delete the folder and start from scratch without changing the system at all...

npm has two modes: local and global. It's normal to put app dependencies locally -- list them in package.json, and use npm install to install them all. Commonly, programmer's tools are installed globally, shared among apps.

That said, you can install those tools locally so different projects can have different versions. I highly recommend it. You run them with ./node_modules/.bin/command rather than just command -- and listing them in scripts in package.json, you can use 'npm run foo' as a shortcut to them.

Aria

[John Shaver]

On Dec 12, 2014 5:04 PM, "Sachinthya Wagaarachchi" <xco...@gmail.com> wrote:
>
> I am starting to learn Node and MEANJS at the same time, and want to have a development folder that is independent. I don't know how to go about it... I have used Mongo and AngulaJS with Pyramid. Here's what I think I want. (Using linux mint, btw)
>
> + I want an independent environment that doesn't change the system. For instance, when I develop using Pyramid, I use a python virtual environment which I can basically delete without effecting the system. I don't know if Node has something like that.

> + If that's not possible, what's the best way to have sort of two independent decoupled projects on the same system but with different (and maybe conflicting) dependancies?

You don't have to see install modules globally, you can install them to the directory.  That might be the simple solution.  npm install -g installs the module for the whole system.  Without the g switch (default) it installs for just the current directory and sub directories.

> + I don't want a virtual machine, just something comparable to venv in python (http://docs.python-guide.org/en/latest/dev/virtualenvs/)

I'm pretty new to node myself, but I'm not aware of anything similar to venv.  The local modules takes care of module versions, but not the version of node itself.

I know you said no virtual machines, but Vagrant is really quite nice to work with, although it takes a bit of setup.

-John

[Sachinthya Wagaarachchi]

Nice, Thanks guys. Sorry for the ignorance :)

[Javier Hernández Antúnez]

Also, if you need to switch between different versions of node you can use nvm

https://github.com/creationix/nvm

My 2 cents,
Javi

> --
> Job board: http://jobs.nodejs.org/
> New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
> Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> ---
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
> To post to this group, send email to nod...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAMbK04wsRowPUCh97YisvqmHdP334EH3pD5g%3Dqwgyf7tbwmEHA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

[zladuric]

Sa Sachi has said, the only thing you might want to use that's globally affecting is the version of Node yourself (like Python 2 or 3).

It's a rare thing, you would usually either use one version, or just update it to latest at all times. But if you have a rare need to update that, then n or nvm are good solutions: https://www.npmjs.com/package/nvm or https://www.npmjs.com/package/n.

Now, with this, there _might_ be an issue of global modules. For example, you want to use bower globally. It's doable for most things, but in in an unlikely event that you want cli versions of a module, from multiple versions of that module, I think it would not work.

So just use n and off you go.

[Irakli Nadareishvili]

Definite +1 for nvm https://github.com/creationix/nvm

[Alex]

I like nave for managing node versions. It is a simple shell script. I do not know if it is as well maintained as NVM. I do know that NVM once had a horrible bug merged in (the infamous "rm -rf /usr"), but I think it is better maintained now.

Anyway, here is nave:

https://github.com/isaacs/nave

Now, there is a lot of wisdom in what Aria said. Just avoiding global installs, whenever possible, is a good idea. A lot of times, when someone new to node asks about global installs, they are still thinking the ruby way (or <shudder> the CPAN way). With Ruby gems, dependencies are frequently installed globally. NPM prefers to bundle all dependencies locally.

You should pretend that "global installs" are the same as "global variables." You have probably heard that this is a code smell.

(For the rest of my post I am going to talk about grunt. This is because it is a common command line tool. If you are not familiar with it, it is a generic task runner that is used to minify front end CSS and JavaScript, and for many other things. Search on it and read the website -- there is excellent documentation.)

Suppose you want to standardize a version of node and grunt across a lot of frontend web applications (requires local install) but you also want freedom to run a staging application on 0.11.x so you can play around with ES6 harmony generators and koa and galaxy. Then a version manager makes sense.

You can download nave.sh to /usr/bin/nave and then execute

nave use stable
npm install -g grunt-cli

and nave will download and/or compile the latest stable version of node. And then it will install grunt.

Or, if you want V8 features from harmony, you can exit the other shell and do this:

nave use latest
node --harmony my-awesome-koa-app.js

and voìla, you have generators!

I know one drawback with nave is there does not seem to be a way to migrate global modules to a new version. E.g., if you installed grunt globally on node 0.10.32 and then update to 0.10.33, you have to reinstall grunt on the new version. Maybe NVM handles that situation. At any rate, you should only ever install a few modules globally:

* grunt-cli
* docpad
* insert other framework with CLI commands...

An instructive historical note about grunt-cli: there was originally only one grunt module, which many people installed globally, but then they decided to split out a minimal subset of functionality out of the main "grunt" module and into a new module called "grunt-cli." So there's "grunt-cli" (typically global) and "grunt" (should be local). In other words, the maintainers of grunt recognized that global installs are problematic and so they split out a minimum of functionality into a separate module to balance this out.

One final thing: if you are thinking of putting ./node_modules/.bin into your path, I would advise against that from a security standpoint. You never want to have anything in your current directory automatically included in the path. You are asking for trouble, security-wise.