debrouwere · December 17, 2010 11:53 · pzhlkj6612 · Mar 12, 2023 · isaacs · Mar 12, 2023
diff --git a/gistfile1.sh b/gistfile1.sh
 # run this in a test directory using a regular bash prompt to get an idea of how virtual environments would work, roughly
 alias npm-env-init="mkdir ./env; mkdir ./env/packages; echo 'root = ./env/packages' > ./env/.npmrc; echo 'Created a new virtual environment for node packages in ./env'"
 alias npm-env-workon="export npm_config_userconfig=./env/.npmrc; export NODE_PATH=./env/packages;"
 alias npm-env-ls="nvp workon; nvm ls active;"
 # we make a virtual environment
 npm-env-init
 # we switch to that virtual environment
 npm-env-workon
 # we install a package
 npm install underscore
 # ... which is installed into the virtual environment
 ls env/packages/underscore
 # ... and entirely isolated from anything that's installed sitewide, 
 # which we can check because nvm ls active will only list underscore
 # and nothing else
 npm ls active

 # besides the obvious advantage of being able to control what packages
 # and which versions get used per project, which arguably can be accomplished
 # with an npm bundle, true virtual environments could enable the following
 # nifty behavior:
 npm ls active > requirements.txt
 cat requirements.txt | xargs -I % npm install %
 # The advantage over bundles being that this avoids having to specify
 # dependencies manually, and that you don't have to create a package.json
 # file if your project isn't really a package anyway.
	# run this in a test directory using a regular bash prompt to get an idea of how virtual environments would work, roughly
	alias npm-env-init="mkdir ./env; mkdir ./env/packages; echo 'root = ./env/packages' > ./env/.npmrc; echo 'Created a new virtual environment for node packages in ./env'"
	alias npm-env-workon="export npm_config_userconfig=./env/.npmrc; export NODE_PATH=./env/packages;"
	alias npm-env-ls="nvp workon; nvm ls active;"
	# we make a virtual environment
	npm-env-init
	# we switch to that virtual environment
	npm-env-workon
	# we install a package
	npm install underscore
	# ... which is installed into the virtual environment
	ls env/packages/underscore
	# ... and entirely isolated from anything that's installed sitewide,
	# which we can check because nvm ls active will only list underscore
	# and nothing else
	npm ls active

	# besides the obvious advantage of being able to control what packages
	# and which versions get used per project, which arguably can be accomplished
	# with an npm bundle, true virtual environments could enable the following
	# nifty behavior:
	npm ls active > requirements.txt
	cat requirements.txt \| xargs -I % npm install %
	# The advantage over bundles being that this avoids having to specify
	# dependencies manually, and that you don't have to create a package.json
	# file if your project isn't really a package anyway.