Giter Club home page Giter Club logo

nodenv-package-json-engine's Introduction

Seamlessly manage your app’s Node environment with nodenv.

Use nodenv to pick a Node version for your application and guarantee that your development environment matches production. Put nodenv to work with npm for painless Node upgrades and bulletproof deployments.

Powerful in development. Specify your app's Node version once, in a single file. Keep all your teammates on the same page. No headaches running apps on different versions of Node. Just Works™ from the command line. Override the Node version anytime: just set an environment variable.

Rock-solid in production. Your application's executables are its interface with ops. With nodenv and you'll never again need to cd in a cron job or Chef recipe to ensure you've selected the right runtime. The Node version dependency lives in one place—your app—so upgrades and rollbacks are atomic, even when you switch versions.

One thing well. nodenv is concerned solely with switching Node versions. It's simple and predictable. A rich plugin ecosystem lets you tailor it to suit your needs. Compile your own Node versions, or use the node-build plugin to automate the process. Specify per-application environment variables with nodenv-vars. See more plugins on the wiki.

Why choose nodenv?

Table of Contents

How It Works

At a high level, nodenv intercepts Node commands using shim executables injected into your PATH, determines which Node version has been specified by your application, and passes your commands along to the correct Node installation.

Understanding PATH

When you run a command like node or npm, your operating system searches through a list of directories to find an executable file with that name. This list of directories lives in an environment variable called PATH, with each directory in the list separated by a colon:

/usr/local/bin:/usr/bin:/bin

Directories in PATH are searched from left to right, so a matching executable in a directory at the beginning of the list takes precedence over another one at the end. In this example, the /usr/local/bin directory will be searched first, then /usr/bin, then /bin.

Understanding Shims

nodenv works by inserting a directory of shims at the front of your PATH:

~/.nodenv/shims:/usr/local/bin:/usr/bin:/bin

Through a process called rehashing, nodenv maintains shims in that directory to match every Node command across every installed version of Node—node, npm, and so on.

Shims are lightweight executables that simply pass your command along to nodenv. So with nodenv installed, when you run, say, npm, your operating system will do the following:

  • Search your PATH for an executable file named npm
  • Find the nodenv shim named npm at the beginning of your PATH
  • Run the shim named npm, which in turn passes the command along to nodenv

Choosing the Node Version

When you execute a shim, nodenv determines which Node version to use by reading it from the following sources, in this order:

  1. The NODENV_VERSION environment variable, if specified. You can use the nodenv shell command to set this environment variable in your current shell session.

  2. The first .node-version file found by searching the directory of the script you are executing and each of its parent directories until reaching the root of your filesystem.

  3. The first .node-version file found by searching the current working directory and each of its parent directories until reaching the root of your filesystem. You can modify the .node-version file in the current working directory with the nodenv local command.

  4. The global ~/.nodenv/version file. You can modify this file using the nodenv global command. If the global version file is not present, nodenv assumes you want to use the "system" Node—i.e. whatever version would be run if nodenv weren't in your path.

Locating the Node Installation

Once nodenv has determined which version of Node your application has specified, it passes the command along to the corresponding Node installation.

Each Node version is installed into its own directory under ~/.nodenv/versions. For example, you might have these versions installed:

  • ~/.nodenv/versions/0.10.36/
  • ~/.nodenv/versions/0.12.0/
  • ~/.nodenv/versions/iojs-1.0.0/

Version names to nodenv are simply the names of the directories or symlinks in ~/.nodenv/versions.

Installation

Using Package Managers

  1. Install nodenv using one of the following approaches.

    Homebrew

    On macOS or Linux, we recommend installing nodenv with Homebrew.

    brew install nodenv

    Debian, Ubuntu, and their derivatives

    Presently, nodenv is not available in the Debian or Ubuntu package repositories. Consider contributing!

    Arch Linux and its derivatives

    Archlinux has an AUR Package for nodenv and you can install it from the AUR using the instructions from this wiki page.

  2. Set up nodenv in your shell.

    nodenv init

    Follow the printed instructions to set up nodenv shell integration.

  3. Close your Terminal window and open a new one so your changes take effect.

  4. Verify that nodenv is properly set up using this nodenv-doctor script:

    curl -fsSL https://github.com/nodenv/nodenv-installer/raw/main/bin/nodenv-doctor | bash
    Checking for `nodenv' in PATH: /usr/local/bin/nodenv
    Checking for nodenv shims in PATH: OK
    Checking `nodenv install' support: /usr/local/bin/nodenv-install (node-build 3.0.22-4-g49c4cb9)
    Counting installed Node versions: none
      There aren't any Node versions installed under `~/.nodenv/versions'.
      You can install Node versions like so: nodenv install 2.2.4
    Auditing installed plugins: OK
  5. That's it! Installing nodenv includes node-build, so now you're ready to install some Node versions using nodenv install.

Basic GitHub Checkout

For a more automated install, you can use nodenv-installer. If you prefer a manual approach, follow the steps below.

This will get you going with the latest version of nodenv without needing a systemwide install.

  1. Clone nodenv into ~/.nodenv.

    git clone https://github.com/nodenv/nodenv.git ~/.nodenv

    Optionally, try to compile dynamic bash extension to speed up nodenv. Don't worry if it fails; nodenv will still work normally:

    cd ~/.nodenv && src/configure && make -C src
  2. Add ~/.nodenv/bin to your $PATH for access to the nodenv command-line utility.

    • For bash:

      Ubuntu Desktop users should configure ~/.bashrc:

      echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bashrc

      On other platforms, bash is usually configured via ~/.bash_profile:

      echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.bash_profile
    • For Zsh:

      echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.zshrc
    • For Fish shell:

      set -Ux fish_user_paths $HOME/.nodenv/bin $fish_user_paths
  3. Set up nodenv in your shell.

    ~/.nodenv/bin/nodenv init

    Follow the printed instructions to set up nodenv shell integration.

  4. Restart your shell so that PATH changes take effect. (Opening a new terminal tab will usually do it.)

  5. Verify that nodenv is properly set up using this nodenv-doctor script:

    curl -fsSL https://github.com/nodenv/nodenv-installer/raw/main/bin/nodenv-doctor | bash
    Checking for `nodenv' in PATH: /usr/local/bin/nodenv
    Checking for nodenv shims in PATH: OK
    Checking `nodenv install' support: /usr/local/bin/nodenv-install (node-build 3.0.22-4-g49c4cb9)
    Counting installed Node versions: none
      There aren't any Node versions installed under `~/.nodenv/versions'.
      You can install Node versions like so: nodenv install 2.2.4
    Auditing installed plugins: OK
  6. (Optional) Install node-build, which provides the nodenv install command that simplifies the process of installing new Node versions.

Upgrading with Git

If you've installed nodenv manually using Git, you can upgrade to the latest version by pulling from GitHub:

cd ~/.nodenv
git pull

To use a specific release of nodenv, check out the corresponding tag:

$ cd ~/.nodenv
$ git fetch
$ git checkout v0.3.0

Alternatively, check out the nodenv-update plugin which provides a command to update nodenv along with all installed plugins.

$ nodenv update

Updating the list of available Node versions

If you're using the nodenv install command, then the list of available Node versions is not automatically updated when pulling from the nodenv repo. To do this manually:

cd ~/.nodenv/plugins/node-build
git pull

How nodenv hooks into your shell

Skip this section unless you must know what every line in your shell profile is doing.

nodenv init is the only command that crosses the line of loading extra commands into your shell. Here's what nodenv init actually does:

  1. Sets up your shims path. This is the only requirement for nodenv to function properly. You can do this by hand by prepending ~/.nodenv/shims to your $PATH.

  2. Installs autocompletion. This is entirely optional but pretty useful. Sourcing ~/.nodenv/completions/nodenv.bash will set that up. There is also a ~/.nodenv/completions/nodenv.zsh for Zsh users.

  3. Rehashes shims. From time to time you'll need to rebuild your shim files. Doing this automatically makes sure everything is up to date. You can always run nodenv rehash manually.

  4. Installs the sh dispatcher. This bit is also optional, but allows nodenv and plugins to change variables in your current shell, making commands like nodenv shell possible. The sh dispatcher doesn't do anything invasive like override cd or hack your shell prompt, but if for some reason you need nodenv to be a real script rather than a shell function, you can safely skip it.

Run nodenv init - for yourself to see exactly what happens under the hood.

Installing Node versions

The nodenv install command doesn't ship with nodenv out of the box, but is provided by the node-build project. If you installed it as part of GitHub checkout process outlined above you should be able to:

# list latest stable versions:
nodenv install -l

# list all local versions:
nodenv install -L

# install a Node version:
nodenv install 16.13.2

Set a Node version to finish installation and start using commands nodenv global 18.14.1 or nodenv local 18.14.1

Alternatively to the install command, you can download and compile Node manually as a subdirectory of ~/.nodenv/versions/. An entry in that directory can also be a symlink to a Node version installed elsewhere on the filesystem. nodenv doesn't care; it will simply treat any entry in the versions/ directory as a separate Node version. Additionally, nodenv has special support for an lts/ subdirectory inside versions/. This works great with the nodenv-aliases plugin, for example:

cd ~/.nodenv/versions
mkdir lts

# Create a symlink that allows to use "lts/erbium" as a nodenv version
# that always points to the latest Node 12 version that is installed.
ln -s ../12 lts/erbium

Uninstalling Node versions

As time goes on, Node versions you install will accumulate in your ~/.nodenv/versions directory.

To remove old Node versions, simply rm -rf the directory of the version you want to remove. You can find the directory of a particular Node version with the nodenv prefix command, e.g. nodenv prefix 0.8.22.

The node-build plugin provides an nodenv uninstall command to automate the removal process.

Uninstalling nodenv

The simplicity of nodenv makes it easy to temporarily disable it, or uninstall from the system.

  1. To disable nodenv managing your Node versions, simply remove the nodenv init line from your shell startup configuration. This will remove nodenv shims directory from $PATH, and future invocations like node will execute the system Node version, as before nodenv.

    While disabled, nodenv will still be accessible on the command line, but your Node apps won't be affected by version switching.

  2. To completely uninstall nodenv, perform step (1) and then remove its root directory. This will delete all Node versions that were installed under `nodenv root`/versions/ directory:

     rm -rf `nodenv root`
    

    If you've installed nodenv using a package manager, as a final step perform the nodenv package removal:

    • Homebrew: brew uninstall nodenv
    • Archlinux and its derivatives: sudo pacman -R nodenv

Command Reference

Like git, the nodenv command delegates to subcommands based on its first argument. The most common subcommands are:

nodenv local

Sets a local application-specific Node version by writing the version name to a .node-version file in the current directory. This version overrides the global version, and can be overridden itself by setting the NODENV_VERSION environment variable or with the nodenv shell command.

nodenv local 0.10.0

When run without a version number, nodenv local reports the currently configured local version. You can also unset the local version:

nodenv local --unset

nodenv global

Sets the global version of Node to be used in all shells by writing the version name to the ~/.nodenv/version file. This version can be overridden by an application-specific .node-version file, or by setting the NODENV_VERSION environment variable.

nodenv global 0.10.26

The special version name system tells nodenv to use the system Node (detected by searching your $PATH).

When run without a version number, nodenv global reports the currently configured global version.

nodenv shell

Sets a shell-specific Node version by setting the NODENV_VERSION environment variable in your shell. This version overrides application-specific versions and the global version.

nodenv shell 0.11.11

When run without a version number, nodenv shell reports the current value of NODENV_VERSION. You can also unset the shell version:

nodenv shell --unset

Note that you'll need nodenv's shell integration enabled (step 3 of the installation instructions) in order to use this command. If you prefer not to use shell integration, you may simply set the NODENV_VERSION variable yourself:

export NODENV_VERSION=0.10.26

nodenv versions

Lists all Node versions known to nodenv, and shows an asterisk next to the currently active version.

$ nodenv versions
  0.8.22
  0.9.12
  * 0.10.0 (set by /Users/will/.nodenv/version)

This will also list symlinks to specific Node versions inside the ~/.nodenv/versions or ~/.nodenv/versions/lts directories.

nodenv version

Displays the currently active Node version, along with information on how it was set.

$ nodenv version
0.10.0 (set by /Users/OiNutter/.nodenv/version)

nodenv rehash

Installs shims for all Node executables known to nodenv (i.e., ~/.nodenv/versions/*/bin/* and ~/.nodenv/versions/lts/*/bin/*). Run this command after you install a new version of Node, or install an npm package that provides an executable binary.

$ nodenv rehash

note: the package-rehash plugin automatically runs nodenv rehash whenever an npm package is installed globally

nodenv which

Displays the full path to the executable that nodenv will invoke when you run the given command.

$ nodenv which npm
/Users/will/.nodenv/versions/0.10.26/bin/npm

nodenv whence

Lists all Node versions with the given command installed.

$ nodenv whence npm
0.10.0
0.9.12
0.8.22

Environment variables

You can affect how nodenv operates with the following settings:

name default description
NODENV_VERSION Specifies the Node version to be used.
Also see nodenv shell
NODENV_ROOT ~/.nodenv Defines the directory under which Node versions and shims reside.
Also see nodenv root
NODENV_DEBUG Outputs debug information.
Also as: nodenv --debug <subcommand>
NODENV_HOOK_PATH see wiki Colon-separated list of paths searched for nodenv hooks.
NODENV_DIR $PWD Directory to start searching for .node-version files.

Development

The nodenv source code is hosted on GitHub. It's clean, modular, and easy to understand, even if you're not a shell hacker.

Tests are executed using Bats:

$ bats test
$ bats test/<file>.bats

Please feel free to submit pull requests and file bugs on the issue tracker.

Credits

Forked from Sam Stephenson's rbenv by Will McKenzie and modified for node.

nodenv-package-json-engine's People

Contributors

depfu[bot] avatar hurrymaplelad avatar jasonkarns avatar neersighted avatar novemberborn avatar toc-me[bot] avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

nodenv-package-json-engine's Issues

Vendor sh-semver dep differently

Discussion:

The current npm script (curl) for updating the sh-semver dep is useful. However, it has some deficiencies. Most notably, there is no indication which version is currently bundled.

Some options:

  1. wait and hope for qzb/sh-semver#9 to be merged and we can just add it as an npm dependency
  2. git submodule
  3. git subtree

No. 1 is the best option. But if that PR isn't merged in a few weeks, I suggest we move to 2 or 3. Option 2 has the benefit of being the most well-known. However, submodules aren't typically fetched automatically and as this plugin is likely installed via git in half of all installations, that rather rules this out. (Unless there's a way we can ensure that git installations get the submodule automatically?)

Option 3 has the benefits of getting actual sha/commit references to the sh-semver repo so we know precisely which revision of the dependency we are using. Using the --squash option, we can keep subtree from importing all of sh-semver's history. And the actual contents of sh-semver's repo will be in our repo, a single git-clone of this repo is sufficient without any submodule fetching necessary. Downsides: our repo would contain the full repo of sh-semver, not just the semver.sh file itself. But this can be avoided with some more pre/post scripting (if desired).

For reference, the step for merging subtree is:

git subtree add --prefix deps/sh-semver https://github.com/qzb/sh-semver master --squash

And later to get latest:

git subtree pull --prefix deps/sh-semver https://github.com/qzb/sh-semver master --squash

`nodenv version-name` doesn't recognize this plugin

package.json has engines.node specified:

$ cat package.json 
{
  "engines": {
    "node": "6.10.3",
    // ...

node -v then behaves as expected:

$ node -v
v6.10.3

However, node version (and node version-name) do not behave as expected (they are returning my globally set version):

$ nodenv version
8.9.4 (set by /Users/i2190/.nodenv/version)

$ nodenv version-name
8.9.4

Let NODENV_VERSION take precedence

Like .node-version, it'd be useful if NODENV_VERSION could take precedence. I have a package.json which allows Node.js >=4. This plugin automatically selects the highest version I have installed, which makes it hard to test on older Node.js versions.

Better instructions to verify an installation?

Once you've installed the plugin you can verify that it's working by cding into a project that has a package.json file with engines and does not have a .node-version file. From anywhere in the project's tree, run nodenv which node

Doing this in a project that specified a node version that was not currently installed just caused my nodenv to hang (which made me think the plugin was not correctly installed) Perhaps there is a more robust way to verify an installation?

Noisy warnings about non semver-compatible nodes

Error message (or warning, really):

/usr/local/var/nodenv/plugins/nodenv-package-json-engine/bin/../node_modules/sh-semver/semver.sh: line 142: [: rc: integer expression expected

This occurs when there exists a nodenv version that doesn't conform to semver. Like say, a version named rc or something.

Relative paths broken for Homebrew install

After installing with Homebrew I get this error:

› nodenv which node
/usr/local/bin/nodenv-package-json-engine: line 42: /usr/local/bin/../deps/semver.sh: No such file or directory
package-json-engine: no version satisfying `4.1.2' installed

It's correct, there are no dependencies available in /usr/local; that path is completely wrong. I don't know enough about how Homebrew packages are installed to correct it, but installing via git in the $(nodenv root) directory (the other listed installation method) works perfectly.

potential refactor to avoid `which`

Nothing to do now, but keep an eye on rbenv/rbenv#739

As you know, nodenv doesn't currently have a hook that allows the selected version to be modified in a consistent fashion. The which hook is suboptimal for a couple reasons (duplication of path to bin; misreported version by version-name and version-origin; misreported version in PS1, etc)

The pull request listed above creates two new hooks that would be ideal for injecting package.json version lookup in a consistent way. if it gets merged into rbenv, then it would be quickly merged into nodenv and we could leverage it here as well.

Thanks for the plugin!

Measure and improve performance

This plugin is too slow. When enabled, it makes running nodenv-version-name in shell prompt almost unusable.

Need to track down the cause of the slowness (my money is on JSON.sh) and find ways to speed it up.

limit to only installed versions

Awesome plugin!

Do you have any thoughts around restricting the version to those that are installed? As it stands now (correct me if I'm wrong), the plugin will select the maximum version that satisfies the version spec from versions, regardless whether that version is installed on the machine or not. This would mean that the moment semver.io sees new versions, my local install will stop working. Correct?

I opened an issue for discussion at semver.io to accept a list of versions to match against (still satisfying the semver spec, of course) but I don't have much hope that it would be implemented since the feature is kind of an edge case for them.

As an alternative, we could modify the semver spec from package.json by appending the max installed version. (nodenv versions is already a sorted list. We would just need to grab the last one listed, excluding iojs versions; prepend <= to it, and then append that to the semver.io query) This would effectively limit the semver.io response to installed versions.

Given specified engine: >=4.0.0
Given installed versions: 4.0.0, 4.1.0, 4.2.1
semver.io (given >= 4.0.0) would return 5.0.0
but if we query semver.io with >=4.0.0 <=4.2.1 the response would be 4.2.1

In the case that none of the installed versions match the supplied engine spec, we could default to semver.io's standard query:

Given specified engine: >=4.0.0
Given installed versions: 0.10.0, 0.12.0
semver.io: >=4.0.0 <=0.12.0 returns 5.0.0 (seems to return max available if semver spec excludes everything)

Auto-installation

Hey there 👋

Would you consider an auto-installation feature in your plugin?

Right now, I'm relying on multiple project/hooks/configurations on my setup to achieve that (e.g.: watch the package.json file, auto-install and enable the missing Node.js versions). It would be great to have the whole thing in one place.

I'm willing to create a PR by the way, but as I never contributed to nodenv, I would appreciate some guidance on the API design.

Should this be a subcommand?

I see that this plugin exposes a subcommand, thanks to the bin/nodenv-* executable. Is this intentional? Is this something we expect end users will want to check? I can see the utility in being able to inspect the version that nodenv will pick up from the package.json (for debugging purposes), but there might be easier ways.

I can also see the desire to have it as a subcommand for parity. Presently, there exists nodenv-shell, nodenv-local, and nodenv-global. Each of these can be used as setters or getters. For parity, I would recommend that this plugin expose a similarly named subcommand; perhaps nodenv-package or nodenv-package-json to be more similar in spirit to shell, local, and global. For parity, I would also hope the subcommand would function as a setter and actually write the given version to package.json. Additionally, I would hope it accepts a --unset flag to remove the engine specification from package.json. This would make the interface for the version selection match shell/local/global almost exactly.

And if this plugin should be exposing a subcommand, I would suggest that it conform to the standard of other plugins. That is, offering tab completion, help/usage output, etc.

If it is not desired that this plugin expose a subcommand, then I propose the current executable be moved out of bin/ and into libexec/ following the pattern of other plugins and nodenv itself.

If the vote is to retain the subcommand, I can open separate issues for the other features I mentioned so that their discussion doesn't happen here.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.