Top Related Projects
A better `npm publish`
:package::rocket: Fully automated version management and package publishing
🚀 Automate versioning and package publishing
:trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
📦🔐 A lightweight Node.js private proxy registry
Quick Overview
tj/n is a lightweight Node.js version management tool. It allows users to easily install, switch between, and manage multiple versions of Node.js on their system. This project aims to provide a simple and fast alternative to other Node.js version managers.
Pros
- Lightweight and fast installation process
- Simple and intuitive command-line interface
- Cross-platform support (macOS, Linux, and Windows)
- Written in Bash, making it easy to understand and modify
Cons
- Limited features compared to more comprehensive version managers like nvm
- May require manual PATH configuration on some systems
- Less active development and community support compared to alternatives
- Limited documentation for advanced use cases
Code Examples
# Install the latest LTS version of Node.js
n lts
# Switch to a specific version of Node.js
n 14.17.0
# List installed versions and select one interactively
n
# Remove a specific version of Node.js
n rm 12.22.1
Getting Started
To install n, you can use the following command:
curl -L https://git.io/n-install | bash
After installation, you may need to restart your terminal or run source ~/.bashrc
(or equivalent for your shell) to use n.
Basic usage:
# Install the latest stable version
n stable
# Use a specific version
n 14.17.0
# List installed versions
n ls
For more information and advanced usage, refer to the project's README on GitHub.
Competitor Comparisons
A better `npm publish`
Pros of np
- More comprehensive release workflow, including version bumping and changelog generation
- Better support for monorepos and custom publish scripts
- Active development with frequent updates and bug fixes
Cons of np
- More complex setup and configuration required
- Slower execution due to additional features and checks
- Steeper learning curve for new users
Code Comparison
n:
#!/usr/bin/env node
var n = require('../')
, pkg = require('../package')
, args = process.argv.slice(2);
// Handle --version
if ('-v' == args[0] || '--version' == args[0]) {
console.log(pkg.version);
process.exit(0);
}
np:
#!/usr/bin/env node
import process from 'node:process';
import meow from 'meow';
import updateNotifier from 'update-notifier';
import np from './index.js';
const cli = meow(`
Usage
$ np <version>
Both tools are command-line utilities for managing Node.js versions (n) or publishing npm packages (np). n focuses on simplicity and speed, while np offers a more feature-rich publishing experience. The code snippets show the initial setup of the CLI interfaces, with np using more modern JavaScript syntax and additional dependencies for enhanced functionality.
:package::rocket: Fully automated version management and package publishing
Pros of semantic-release
- Automates the entire package release workflow, including version bumping and changelog generation
- Enforces semantic versioning conventions, ensuring consistent and meaningful version numbers
- Integrates well with CI/CD pipelines for automated releases
Cons of semantic-release
- Steeper learning curve and more complex setup compared to n
- Requires specific commit message conventions to function properly
- May be overkill for smaller projects or those with infrequent releases
Code Comparison
semantic-release configuration (.releaserc.json
):
{
"branches": ["main"],
"plugins": [
"@semantic-release/commit-analyzer",
"@semantic-release/release-notes-generator",
"@semantic-release/npm",
"@semantic-release/github"
]
}
n usage:
n 12.18.3
n latest
n lts
Summary
semantic-release is a comprehensive solution for automating the entire release process, enforcing semantic versioning, and generating changelogs. It's ideal for larger projects with frequent releases and teams that follow strict commit conventions. However, it has a steeper learning curve and more complex setup compared to n.
n, on the other hand, is a simpler tool focused on Node.js version management. It's easier to use and set up, making it more suitable for individual developers or smaller projects that primarily need quick version switching capabilities.
🚀 Automate versioning and package publishing
Pros of release-it
- More comprehensive release automation with support for various tasks like bumping versions, generating changelogs, and creating Git tags
- Highly configurable with extensive options for customizing the release process
- Active development and regular updates
Cons of release-it
- Steeper learning curve due to its more complex feature set
- Requires more configuration and setup compared to n's simplicity
- Larger package size and more dependencies
Code comparison
n:
n 12.18.3
n latest
n rm 12.18.3
release-it:
release-it
release-it minor --ci
release-it --dry-run
Summary
n is a simple and lightweight Node.js version manager, focused on easy installation and switching between Node.js versions. release-it, on the other hand, is a comprehensive release automation tool that handles various aspects of the software release process.
While n excels in simplicity and ease of use for managing Node.js versions, release-it offers a more feature-rich experience for automating the entire release workflow. n is ideal for developers who primarily need to manage Node.js versions, while release-it is better suited for projects requiring a more sophisticated release process with version bumping, changelog generation, and Git tagging.
The choice between the two depends on the specific needs of the project and the level of automation desired in the release process.
:trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
Pros of standard-version
- Automates versioning and changelog generation based on commit messages
- Supports Conventional Commits specification for structured commit messages
- Integrates well with npm and package.json for version management
Cons of standard-version
- More complex setup and configuration compared to n
- Requires adherence to specific commit message format
- May be overkill for simple projects or individual developers
Code comparison
standard-version:
{
"scripts": {
"release": "standard-version"
}
}
n:
n latest
n 14.17.0
n lts
Key differences
- Purpose: standard-version focuses on versioning and changelog generation, while n is a Node.js version manager
- Scope: standard-version is project-specific, n is system-wide
- Functionality: standard-version automates release processes, n simplifies Node.js version switching
Use cases
standard-version:
- Projects following semantic versioning
- Teams requiring structured release processes
- Automated changelog generation
n:
- Developers working with multiple Node.js versions
- Quick switching between Node.js versions
- Simple installation and management of Node.js
Community and maintenance
Both projects are well-maintained and have active communities. standard-version has more recent updates and a larger number of contributors, while n has a longer history and is more focused in its scope.
:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
Pros of Lerna
- Designed for managing JavaScript projects with multiple packages
- Optimizes workflows for monorepo setups
- Provides tools for versioning and publishing packages
Cons of Lerna
- Steeper learning curve due to more complex features
- Can be overkill for smaller projects or single-package repositories
- Requires more configuration and setup compared to simpler alternatives
Code Comparison
Lerna (example of package management):
{
"name": "my-lerna-repo",
"private": true,
"workspaces": [
"packages/*"
],
"scripts": {
"bootstrap": "lerna bootstrap"
}
}
n (example of version management):
n 12.18.3
n latest
n lts
Key Differences
- Purpose: Lerna focuses on multi-package repository management, while n is primarily for Node.js version management
- Scope: Lerna has a broader scope, handling package versioning, publishing, and dependencies, whereas n is more specialized for Node.js version switching
- Complexity: Lerna offers more features but requires more setup, while n is simpler and more straightforward for its specific use case
Use Cases
- Choose Lerna for managing large-scale JavaScript projects with multiple packages or monorepo setups
- Opt for n when you need a lightweight tool for quickly switching between Node.js versions on your development machine
📦🔐 A lightweight Node.js private proxy registry
Pros of Verdaccio
- Provides a full-featured private npm registry
- Supports authentication and access control
- Can be used as a caching proxy for npm
Cons of Verdaccio
- More complex setup and configuration
- Requires more system resources
- Steeper learning curve for beginners
Code Comparison
Verdaccio configuration example:
storage: ./storage
auth:
htpasswd:
file: ./htpasswd
uplinks:
npmjs:
url: https://registry.npmjs.org/
packages:
'@*/*':
access: $all
publish: $authenticated
proxy: npmjs
n doesn't have a direct code comparison as it's a version manager, not a registry. Its usage is typically command-line based:
n 12.18.3
n latest
n lts
Summary
Verdaccio is a private npm registry that offers more advanced features for package management, while n is a simpler tool focused on Node.js version management. Verdaccio is better suited for teams or projects requiring a private registry, while n is ideal for developers who frequently switch between Node.js versions.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
n
â Interactively Manage Your Node.js Versions
Node.js version management: no subshells, no profile setup, no convoluted API, just simple.
n
â Interactively Manage Your Node.js Versions
Supported Platforms
n
is supported on macOS, Linux, including with Windows Subsystem for Linux, and various other unix-like systems.
It is written as a BASH script but does not require you to use BASH as your command shell.
n
does not work in native shells on Microsoft Windows (like PowerShell), or Git for Windows BASH, or with the Cygwin DLL.
Installation
If you already have Node.js installed, an easy way to install n
is using npm
:
npm install -g n
The default root location used when running n
is /usr/local
where a normal user does not have write permission. You may strike the same sort of permission error when using npm to install global modules, like the above command. You have three main options:
- change the ownership of the relevant directories to yourself (see below)
- tell
n
to use a custom location where you do have write permissions (seeN_PREFIX
) - put
sudo
in front of the command to run it as super user
n
caches Node.js versions in subdirectory n/versions
. The active Node.js version is installed in subdirectories bin
, include
, lib
, and share
.
To take ownership of the system directories (option 1):
# make cache folder (if missing) and take ownership
sudo mkdir -p /usr/local/n
sudo chown -R $(whoami) /usr/local/n
# make sure the required folders exist (safe to execute even if they already exist)
sudo mkdir -p /usr/local/bin /usr/local/lib /usr/local/include /usr/local/share
# take ownership of Node.js install destination folders
sudo chown -R $(whoami) /usr/local/bin /usr/local/lib /usr/local/include /usr/local/share
If npm
is not yet available, one way to bootstrap an install is to download and run n
directly. To install the lts
version of Node.js:
curl -fsSL https://raw.githubusercontent.com/tj/n/master/bin/n | bash -s lts
# If you want n installed, you can use npm now.
npm install -g n
Alternatively, you can clone this repo and
make install
which defaults to /usr/local/bin/n
. To install n
in a custom location such as $CUSTOM_LOCATION/bin/n
, run PREFIX=$CUSTOM_LOCATION make install
.
Third Party Installers
On macOS with Homebrew you can install the n formula.
brew install n
Or on macOS with MacPorts you can install the n port:
port install n
On Linux and macOS, n-install allows installation directly from GitHub; for instance:
curl -L https://bit.ly/n-install | bash
n-install sets both PREFIX
and N_PREFIX
to $HOME/n
, installs n
to $HOME/n/bin
, modifies the initialization files of supported shells to export N_PREFIX
and add $HOME/n/bin
to the PATH
, and installs the latest LTS Node.js version.
As a result, both n
itself and all Node.js versions it manages are hosted inside a single, optionally configurable directory, which you can later remove with the included n-uninstall
script. n-update
updates n
itself to the latest version. See the n-install repo for more details.
Replacing a previous node install
Changing from a previous Node.js installed to a different location may involve a few extra steps. See docs for changing node location for a walk-through example of switching from using Homebrew to using n
to manage Node.js.
You have a problem with multiple versions if after installing node you see the "installed" and "active" locations are different:
% n lts
copying : node/20.12.2
installed : v20.12.2 to /usr/local/bin/node
active : v21.7.3 at /opt/homebrew/bin/node
Installing Node.js Versions
Simply execute n <version>
to download and install a version of Node.js. If <version>
has already been downloaded, n
will install from its cache.
n 10.16.0
n lts
Execute n
on its own to view your downloaded versions, and install the selected version.
$ n
node/4.9.1
ο node/8.11.3
node/10.15.0
Use up/down arrow keys to select a version, return key to install, d to delete, q to quit
(You can also use j and k to select next or previous version instead of using arrows, or ctrl+n and ctrl+p.)
If the active node version does not change after install, try opening a new shell in case seeing a stale version.
Specifying Node.js Versions
There are a variety of ways of specifying the target Node.js version for n
commands. Most commands use the latest matching version, and n ls-remote
lists multiple matching versions.
Numeric version numbers can be complete or incomplete, with an optional leading v
.
4.9.1
8
: 8.x.y versionsv6.1
: 6.1.x versions
There are labels for two especially useful versions:
lts
: newest Long Term Support official releaselatest
,current
: newest official release
There is an auto
label to read the target version from a file in the current directory, or any parent directory. n
looks for in order:
.n-node-version
: version on single line. Custom ton
..node-version
: version on single line. Used by multiple tools: node-version-usage.nvmrc
: version on single line. Used bynvm
.- if no version file found, look for
engine
as below.
The engine
label looks for a package.json
file and reads the engines
field to determine compatible Node.js. Requires an installed version of jq
or node
, and uses npx semver
to resolve complex ranges.
There is support for the named release streams:
argon
,boron
,carbon
: codenames for LTS release streams
These Node.js support aliases may be used, although simply resolve to the latest matching version:
active
,lts_active
,lts_latest
,lts
,current
,supported
The last version form is for specifying other releases available using the name of the remote download folder optionally followed by the complete or incomplete version.
nightly
test/v11.0.0-test20180528
rc/10
Removing Versions
Remove some cached versions:
n rm 0.9.4 v0.10.0
Removing all cached versions except the installed version:
n prune
Remove the installed Node.js (does not affect the cached versions). This can be useful to revert to the system version of node (if in a different location), or if you no longer wish to use node and npm, or are switching to a different way of managing them.
n uninstall
Using Downloaded Node.js Versions Without Reinstalling
There are three commands for working directly with your downloaded versions of Node.js, without reinstalling.
You can show the path to the downloaded node
version:
$ n which 6.14.3
/usr/local/n/versions/6.14.3/bin/node
Or run a downloaded node
version with the n run
command:
n run 8.11.3 --debug some.js
Or execute a command with PATH
modified so node
and npm
will be from the downloaded Node.js version.
(NB: npm
run this way will be using global node_modules from the target node version folder.)
n exec 10 my-script --fast test
n exec lts zsh
Preserving npm
A Node.js install normally also includes npm
, npx
, and corepack
, but you may wish to preserve your current (especially newer) versions using --preserve
:
$ npm install -g npm@latest
...
$ npm --version
6.13.7
# Node.js 8.17.0 includes (older) npm 6.13.4
$ n -p 8
installed : v8.17.0
$ npm --version
6.13.7
You can make this the default by setting the environment variable to a non-empty string. There are separate environment variables for npm
and corepack
:
export N_PRESERVE_NPM=1
export N_PRESERVE_COREPACK=1
You can be explicit to get the desired behaviour whatever the environment variables:
n --preserve nightly
n --no-preserve latest
Miscellaneous
Command line help can be obtained from n --help
.
List matching remote versions available for download:
n ls-remote lts
n ls-remote latest
n lsr 10
n --all lsr
List downloaded versions in cache:
n ls
Use n
to access cached versions (already downloaded) without internet available.
n --offline 12
Display diagnostics to help resolve problems:
n doctor
Custom Source
If you would like to use a different Node.js mirror which has the same layout as the default https://nodejs.org/dist/, you can define N_NODE_MIRROR
.
The most common example is from users in China who can define:
export N_NODE_MIRROR=https://npmmirror.com/mirrors/node
If the custom mirror requires authentication you can add the url-encoded username and password into the URL. e.g.
export N_NODE_MIRROR=https://encoded-username:encoded-password@host:port/path
There is also N_NODE_DOWNLOAD_MIRROR
for a different mirror with same layout as the default https://nodejs.org/download.
Custom Architecture
By default n
picks the binaries matching your system architecture. For example, on a 64 bit system n
will download 64 bit binaries.
On a Mac with Apple silicon:
- for Node.js 16 and higher,
n
defaults to arm64 binaries which run natively - for older versions of Node.js,
n
defaults to x64 binaries which run in Rosetta 2
You can override the default architecture by using the -a
or --arch
option.
e.g. reinstall latest version of Node.js with x64 binaries:
n rm current
n --arch x64 current
Optional Environment Variables
The n
command downloads and installs to /usr/local
by default, but you may override this location by defining N_PREFIX
.
To change the location to say $HOME/.n
, add lines like the following to your shell initialization file:
export N_PREFIX=$HOME/.n
export PATH=$N_PREFIX/bin:$PATH
If you want to store the downloads under a different location, use N_CACHE_PREFIX
. This does not affect the currently active
node version.
n
defaults to using xz compressed Node.js tarballs for the download if it is likely tar on the system supports xz decompression.
You can override the automatic choice by setting an environment variable to zero or non-zero:
export N_USE_XZ=0 # to disable
export N_USE_XZ=1 # to enable
You can be explicit to get the desired behaviour whatever the environment variable:
n install --use-xz nightly
n install --no-use-xz latest
In brief:
N_NODE_MIRROR
: See Custom sourceN_NODE_DOWNLOAD_MIRROR
: See Custom source- support for NO_COLOR and CLICOLOR=0 for controlling use of ANSI color codes
N_MAX_REMOTE_MATCHES
to change the defaultls-remote
maximum of 20 matching versionsN_PRESERVE_NPM
: See Preserving npmN_PRESERVE_COREPACK
: See Preserving npm
How It Works
n
downloads a prebuilt Node.js package and installs to a single prefix (e.g. /usr/local
). This overwrites the previous version. The bin
folder in this location should be in your PATH
(e.g. /usr/local/bin
).
The downloads are kept in a cache folder to be used for reinstalls. The downloads are also available for limited use using n which
and n run
and n exec
.
The global npm
packages are not changed by the install, with the
exception of npm
itself which is part of the Node.js install.
Top Related Projects
A better `npm publish`
:package::rocket: Fully automated version management and package publishing
🚀 Automate versioning and package publishing
:trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
:dragon: Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.
📦🔐 A lightweight Node.js private proxy registry
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot