GitShow/tj/n
tj

n

Node version management

by tj
Star on GitHubFork

Shell

19.5k stars758 forks99 contributorsActive · 4d agoSince 2011v10.2.0MIT

Meet the team

See all 99 on GitHub →
shadowspawn
shadowspawn355 contributions
tj
tj159 contributions
maxrimue
maxrimue48 contributions
qw3rtman
qw3rtman34 contributions
troy0820
troy082031 contributions
tjwebb
tjwebb27 contributions
73rhodes
73rhodes14 contributions
PeterDaveHello
PeterDaveHello8 contributions

Languages

View on GitHub →
Shell99.8%
Makefile0.2%

Commit activity

Last 12 weeks · 0 commits

Full graph →

Community health

4 of 6 standards met

Community profile →
85
✓README✓License✓Contributing○Code of Conduct○Issue Template✓PR Template

Recent PRs & issues

Active · 1 in progress · Last activity 4d ago
See all on GitHub →
shadowspawn
Add support for alpha versions of nodeOpenPR

See #847 for more background and discussion. Problem Node.js is switching to yearly releases, with alpha -> current -> lts What do we do with labels to support new policy? Solution Keep using and labels, with refined behaviour for : : newest release : newest release ignoring alpha versions Node.js will have periods when there is not a version in its "current" phase. We still match to newest non-alpha, so may be in current or LTS phase. Add some extra handling for: excluding alpha versions from sorting local listing so prerelease comes before release versions Remove from README. ChangeLog

shadowspawn · 4d ago
kanadgupta
Support for `package.json#/devEngines/runtime`OpenIssue

Hi there! I know that looks at [^1] — is there any openness to adding support for ? Looks like the ecosystem is starting to support it more — see below: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines https://github.com/openjs-foundation/package-metadata-interoperability-working-group/blob/main/devengines-field-proposal.md https://nubjs.com/docs/runtime#node-version-resolution https://mise.en.dev/lang/node.html#nvmrc-node-version-and-package-json-support https://pnpm.io/package_json#devenginesruntime [^1]: https://github.com/tj/n#specifying-nodejs-versions

kanadgupta · 1mo ago
shadowspawn
Revise labels for new Node.js Release ScheduleOpenIssue

The Node.js release schedule is changing. The announcement is: https://nodejs-org-git-fork-ulisesgascon-release-announcement-openjs.vercel.app/en/blog/announcements/evolving-the-nodejs-release-schedule Old Node.js terminology (https://nodejs.org/en/about/previous-releases): even: current / active LTS / maintenance LTS odd: current / maintenance New terminology used in announcement: alpha / interim / LTS I think this makes the little used node support labels somewhat obsolete (like ), and is not mentioned. got used in some training material and will retain that as an alias even if do not document. Likewise, stable. Not sure if users will want to target the latest version _after_ it reaches alpha? uses the index information from https://github.com/nodejs/nodejs-dist-indexer and does not do date calculations. I am watching that repo to see if alpha/interim get added to the index.

shadowspawn · 4mo ago

Recent fixes

View closed PRs →
dman777
curl -L https://raw.githubusercontent.com/tj/n/master/bin/n -o n ..... missing n executableClosedIssue

on a fresh install of ubuntu focal server.... without node.... I installed n (from zsh) with It installed everything but the n executable. The actual n executable was missing So, I deleted the n directory and used (from bash shell instead of zsh this time) and everything worked great.

dman777 · 1d ago
zaq42
Need a new label - Transition of LTSClosedIssue

Problem Primary labels and aliases are: , , Until last week, was the newest version of node 24, which will be the next lts version. was (and is stillcurrentlatestactivecurrent25.0.0ltslts_activelts_latestsupported22.21.0labelnn latestn 24activecurrentlts_active2422` is now in maintenance. Image from Node.js Releases: !image Configuration Details

zaq42 · 6mo ago
MikeMcC399
Corepack remains when upgrading to Node.js 25.0.0ClosedIssue

Bug Report Summary Although Node.js 25.0.0 removed Corepack from Node.js , switching from a Node.js version with bundled Corepack, such as one of the Node.js LTS versions, to Node.js which does not distribute Corepack, retains the previously installed Corepack version. Steps to Reproduce Expected Behaviour Node.js no longer bundles Corepack with Node.js, so switching to such a version should not preserve the previously installed Corepack version. The result of switching to Node.js should also be deterministic. Leaving a previously installed version of Corepack in place means that it is not, because it then depends on what version of Node.js (and therefore what version of Corepack) was previously installed. Actual Behaviour Running the steps to reproduce shows Corepack left over from Node.js when switching to Node.js Other Information The Corepack README documents the removal of Corepack from the Node.js bundle starting with Node.js . https://github.com/tj/n/issues/789 already discussed this issue in terms of downgrading. The situation with upgrading to Node.js is new. Given that Corepack is permanently removed from Node.js , and from future versions of Node.js, I suggest that the issue and strategy needs to be revisited. Configuration Details

MikeMcC399 · 6mo ago
Structured data for AI agents

Repository: tj/n. Description: Node version management Stars: 19510, Forks: 758. Primary language: Shell. Languages: Shell (99.8%), Makefile (0.2%). License: MIT. Latest release: v10.2.0 (1y ago). Open PRs: 1, open issues: 3. Last activity: 4d ago. Community health: 85%. Top contributors: shadowspawn, tj, maxrimue, qw3rtman, troy0820, tjwebb, 73rhodes, PeterDaveHello, benatkin, jeromedecoster and others.

·@ofershap

Replace github.com with gitshow.dev