nvm

nvm CVE-2026-118905: a version pattern containing # escaped nvm_ls's sed filter, and GNU sed's e command ran shell. With the README's cdnvm or load-nvmrc hook, cd into a repo with a malicious .nvmrc was enough. Fixed in 0.40.6. Check nvm --version. github.com/nvm-sh/nvm/security/advisories/GHSA-vg…

Your Agent's Shell Isn't Your Shell: 8 Differences That Break Its Commands - Book: RAG Pocket Guide - The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- You typed nvm use 22 ten minutes ago. Your prompt shows the right Node. Then you ask the agent to run the tests, and it reports a syntax error that only an older Node would throw. Or ll is "not found". Or npm test sits there until it times out. Nothing is broken. The agent ran your command in a different kind of shell than the one you type into. It is usually non-interactive and often not a login shell. Its output goes to a pipe or a file, not a terminal. Each of those changes which startup files run and how your tools behave. Eight differences cause most of it. Each one below comes with a command that proves it on your own machine: run it in your terminal, ask the agent to run it too, and compare. First: which shell is the agent in? Bash calls a shell interactive when it is "started without non-option arguments (unless -s is specified) and without the -c option, and whose standard input and standard error are both connected to terminals" (bash(1)). An agent that runs bash -c '...' or zsh -c '...' fails that test before it starts. Two checks tell you what you have. $- lists the shell's option flags, and an interactive shell includes i. test -t 1 is true only when file descriptor 1 is "open and is associated with a terminal" (POSIX test). echo "$-" [ -t 1 ] && echo "stdout is a tty" || echo "stdout is not a tty" Run both yourself, then ask the agent to run them. The difference between the two answers is the rest of this post. The 8 differences 1. zsh -c never reads your .zshrc The zsh docs are short on this: .zshenv "is sourced on all invocations of the shell, unless the -f option is set", while .zshrc "is sourced in interactive shells" and .zlogin "is sourced in login shells" (zsh startup files). Every export PATH=... line you put in .zshrc is invisible to a plain zsh -c. env -i HOME="$HOME" zsh -c 'echo $PATH' \ | tr ':' '\n' > plain.txt env -i HOME="$HOME" TERM="$TERM" zsh -ic 'echo $PATH' \ | tr ':' '\n' > interactive.txt diff plain.txt interactive.txt env -i drops the PATH your terminal already exported. Without it, the child zsh inherits that PATH and the diff shows nothing useful. An agent launched from a GUI or a fresh process does not get your terminal's PATH for free. Every line in the diff is a directory your agent may not have. 2. bash -c reads no startup file at all, except $BASH_ENV An interactive non-login bash "reads and executes commands from ~/.bashrc". A non-interactive one skips that and instead "looks for the variable BASH_ENV in the environment" and runs the file it names (bash(1)). No BASH_ENV, no startup file. bash -c 'type ll' # fails: ll is not found bash -ic 'type ll' # works if ~/.bashrc defines ll 3. Aliases are off in non-interactive bash, even when you source them This one surprises people who "fix" item 2 by sourcing .bashrc in a script. The bash manual: "Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt" (Aliases). echo 'alias ll="ls -l"' > ./aliases.sh bash -c 'source ./aliases.sh; ll' # ll: command not found bash -c 'shopt -s expand_aliases source ./aliases.sh ll' # works The alias has to be defined on an earlier line than the one that uses it, which is why the working version spans three lines. Claude Code works around items 1 to 3 for its own Bash tool. Its docs say that at session start it "sources ~/.zshrc, ~/.bashrc, or ~/.profile depending on your shell, captures the resulting aliases, functions, and shell options, and applies them to every Bash command" (Claude Code tools reference). That covers the agent's own commands. It does not cover what those commands start: a make recipe, a git hook, an npm script or a shell script you wrote all get the plain rules above. GNU make, for one, uses /bin/sh unless the makefile says otherwise, and "the variable SHELL is never set from the environment" (GNU make). !A terminal window split in two: the left half full of familiar aliases and paths, the right half nearly empty Your interactive shell on the left, the agent's -c shell on the right. 4. Claude Code's snapshot is taken once, at session start A captured environment is a photo. Claude Code takes it "at session start" (same page), so the alias you add to .zshrc mid-session, or the tool you install that edits your PATH, does not reach a session that is already running. Codex also snapshots your shell environment: its features.shell_snapshot setting will "Snapshot shell environment to speed up repeated commands", on by default (Codex config reference). The page doesn't say when that snapshot refreshes, so test it. Add alias hello='echo hi' to your startup file, ask the running agent to run type hello, then start a fresh session and ask again. If only the fresh one finds it, restart sessions after you change your shell config. 5. export dies with the command Claude Code's Bash tool "runs each command in a separate process", and "Environment variables don't persist. An export in one command won't be available in the next" (tools reference). The working directory does carry over inside the project, which makes the missing variable more confusing. Ask the agent to run these as two separate commands: export API_URL=https://api.example.com echo "${API_URL:-unset}" The second prints unset. Put the value in the same command line (API_URL=... npm test), or in a file the agent loads (see the fix below). Codex adds a second filter: shell_environment_policy.inherit (all, core or none) sets the "Baseline environment inheritance when spawning subprocesses" (Codex config reference). If your team set it to core or none, a variable exported in the terminal you started Codex from may never reach its commands. 6. nvm use changes one shell, and it isn't the agent's nvm is "a sourced shell function, not an executable binary", "invoked per-shell" (nvm README). Your nvm use 22 edited the PATH of the shell you typed it into. The agent's commands started from somewhere else. zsh -c 'type nvm' # not found: .zshrc never ran nvm alias default 22 # what new shells start with In Claude Code the nvm function can come along with the snapshot, but item 5 still applies: nvm use 22 in one command changes PATH for that command only, and the next npm test runs with the old one. Set the default alias, so every new shell starts on the version you want. 7. Prompt hooks never fire, because there is no prompt direnv "needs to be hooked into the shell", and "Before each prompt it checks for the existence of an .envrc file" (direnv(1)). mise's activation is the same idea: "PATH activation does its work at prompts and directory changes" (mise shims docs). A command the agent runs starts, runs, and exits. It never draws a prompt, so the hook has nothing to fire on, and your .envrc or mise.toml might as well not exist. Both tools ship a one-shot form for exactly this: direnv exec . npm test mise exec -- npm test mise's docs point you the same way: use mise exec or mise run for "CI, scripts, and projects where you do not want to change shell startup files", and shims for programs that "do not start from" the shell you type into. 8. No terminal on stdout, and no job control Claude Code "streams a command's output to a working file as the command runs" (tools reference). stdout is a file, so every tool that checks for a terminal changes behaviour. git only pipes output into a pager "if standard output is a terminal" (git(1)), which helps here. Colour and progress bars usually switch off. A tool that asks a question waits on stdin for an answer nobody types, until the command timeout kills it (two minutes by default in Claude Code, same page). Pass the tool's non-interactive flag (--yes, -y, --no-input) instead. Job control is gone too. set -m is "on by default for interactive shells on systems that support it" (bash(1)), and a -c shell isn't one. fg, bg and Ctrl-Z mean nothing there. bash -c 'echo $-' # no i, no m bash -ic 'echo $-' # i, and m when a terminal is attached For a dev server, let the agent use its own background mechanism (Claude Code has run_in_background) rather than & and fg. The fix: put the environment where every shell reads it Move what the agent needs out of .zshrc and into a place each kind of shell reads. PATH and plain exports go in ~/.zshenv. It runs for every zsh, interactive or not. Keep it quiet and fast, because it also runs for every script: no echo, no slow commands, nothing that prints. # ~/.zshenv: read by every zsh, unless -f is set export PATH="$HOME/.local/bin:$PATH" export EDITOR=vim For bash, point BASH_ENV at a small file with the same lines. Project variables go through direnv or mise, called explicitly. Tell the agent, in your CLAUDE.md or AGENTS.md, to run tests with direnv exec . npm test or mise exec -- npm test. Commands go in a Makefile. A target fixes the shell and the wrapper once, and the agent only has to remember make test: SHELL := /bin/bash test: direnv exec . npm test For Claude Code's own commands, use CLAUDE_ENV_FILE. To make variables persist across Bash commands, the docs say to set CLAUDE_ENV_FILE "to a shell script before launching Claude Code, or use a SessionStart hook to populate it dynamically" (tools reference). The same page says to activate your virtualenv or conda environment before you launch it. Then rerun the two checks from the top, through the agent, and the eight commands above. They should agree with your terminal on everything except i, m and the tty. What Hermes changes, and what it doesn't I build Hermes IDE, so weigh this section with that in mind. Hermes opens every agent, and any plain shell you start, "in a real terminal by default, running the agent's own interface" (README). That changes one layer. The agent's own interface gets a real terminal, so its prompts, approval dialogs and slash commands behave exactly as the vendor built them. It also means you can open a plain shell in a split pane next to the agent and run the checks from this post side by side. !Two real agent sessions side by side in Hermes IDE, Codex and Claude Code, each in its own worktree Codex on orders-types and Claude Code on orders-api, each in its own hermes/ worktree, with the sessions sidebar on the left. It does not change the layer the eight differences live in. When the agent runs a tool command, the agent spawns that process itself, the same way it would in any other terminal. Claude Code still captures its snapshot at start, still drops export between commands, and still sends output to a file. Codex still applies its shell_environment_policy. All eight differences hold inside Hermes. Hermes's own worktree recipe follows the same rules: its setup commands run in sh on macOS and Linux (worktree recipes), and a non-interactive sh won't read your .zshrc either. Hermes is free to download, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It is not affiliated with Nous Research, Anthropic, OpenAI or any agent vendor. Download it or read the source on GitHub. --- If this was useful A lot of what an agent does in that shell is search: rg, grep, git log -S, reading the files that come back. When plain search stops being enough and you want an agent that retrieves the right chunk of code or docs, the RAG Pocket Guide covers chunking, embeddings and reranking for production. It is one of the 8 short books in the Pocket Guides for Developers series, on agents, RAG, prompts, observability, events, databases and system design: the whole series is here. 

nvm's Oct 29 advisory: untrusted version strings can inject sed commands (shell execution with GNU sed). Certain .nvmrc auto-switch hooks expose this on directory entry; plain `nvm use` is unaffected. Upgrade to 0.40.6+. github.com/nvm-sh/nvm/security/advisories/GHSA-vg…

Vue Fes Japan 2026 「 Vite+への貢献と、Team Memberになって見えてきた風景」スピーカーノート 導入 Hello, everyone! My slides are in English, but I will speak in Japanese today, since I am still learning English. I hope you enjoy my talk! みなさん、こんにちは。 今日は、私がこれまでVite+にどんなコントリビューションをしてきたのか、その内容を振り返りたいと思います。 具体的には、実際に取り組んだIssueやPRを紹介しながら、そのとき何を考えていたのか、という話です。 すごく難しい技術の話というよりは、自分が実際にやってきたことの振り返りなので、あまり身構えずに、気楽に聞いてもらえたらと思います。 また、最初は一人のコントリビューターとして関わっていたんですけど、Core Teamに参加してからは、Issueの調査やPRのレビューなど、関わり方も変わっていきました。 今日は、そうした中で、自分の考え方や、OSSに対する見方がどう変わったのかもお話しします。 軽く自己紹介をします。ハバ ナオキ（@naokihaba）と申します。 株式会社ANDPADという会社で、ソフトウェアエンジニアをしています。 趣味では、Vite+のCore Team Memberとして、日々開発に関わっています。 Vite+ とは では、本題に入る前に、Vite+について簡単に紹介します。 Vite+は、Web開発で使うさまざまなツールを、一つにまとめた統合ツールチェーンです。 普段の開発では、開発サーバーを起動したり、テストを実行したり、Lintやフォーマットをしたりしますよね。 そのために、いくつものツールをインストールして、それぞれの設定やコマンドを使い分けていると思います。 Vite+では、こうしたツールをまとめて、vp という一つのCLIから使えるようにしています。 中で使っているツールは、皆さんも知っているものが多いと思います。 開発サーバーやアプリケーションのビルドにはVite、テストにはVitest、LintにはOxlint、フォーマットにはOxfmtを使っています。 これらを、vp devやvp test、vp lintといったコマンドで実行できます。 あとは、ライブラリをビルドするvp packでは、tsdownを使っています。これは、あとで移行の話にも出てきます。 こんなふうに、いろんなツールを一つのCLIから使えるのがVite+です。 では、ここから私が最初にコントリビュートしたときの話をします。 コントリビューターとしての軌跡 私が最初に取り組んだのは、vp createで起きていた問題です。 vp createは、テンプレートを使って新しいプロジェクトを作るコマンドです。 これを自分で使っていたときに、存在しないテンプレート名を指定したら、pnpmの404エラーがそのまま表示されたんですね。 これだと、何を間違えたのか、ちょっとわかりにくいなと思いました。 そこでGitHubを見てみると、同じ問題がIssueとして報告されていました。 vite-plus#828 じゃあ、ちょっとコードを読んでみようと思って、処理を追っていきました。 すると、npmにパッケージが存在するか確認せずに、そのままパッケージマネージャーを実行していたんです。 そのため、テンプレートが見つからない場合も、pnpmのエラーがそのまま表示されていました。 そこで修正したのが、こちらのPRです。 vite-plus#1055 パッケージマネージャーを実行する前に、npmレジストリに問い合わせて、パッケージが存在するか確認するようにしました。 もし404が返ってきたら、テンプレートが見つからなかったことを表示して、処理を止めます。 あわせて、vp create --listで使えるテンプレートを確認できることも案内しています。 これが、Vite+に出した最初のPRでした。 大きな変更ではないんですけど、自分が使っていて困ったところを、実際にコードを読んで直せたんですね。 それがきっかけで、ほかにはどんなIssueがあるんだろうと、少しずつ見るようになりました。 ちょうどこの頃、仕事でもVite+を使ってみたいなと思っていました。 ただ、既存のプロジェクトには、すでにNode.jsのバージョン指定や、いろんなツールの設定がありますよね。 それをVite+に移すとき、どうすればいいんだろう、というのが気になっていました。 そこで見ていたのが、vp migrateです。 これは、既存のプロジェクトをVite+に移行するためのコマンドです。 ただ設定ファイルを書き換えるだけなら簡単そうなんですけど、移行したことで使うNode.jsのバージョンが変わってしまったら、困りますよね。 なので、元の設定をどう読み取るかだけでなく、移行したあとも同じように動くかを考える必要がありました。 そこで最初に取り組んだのが、Node.jsのバージョン設定の移行です。 vite-plus#1158 ここで出てくるのが、.nvmrcと.node-versionです。 どちらも、プロジェクトで使うNode.jsのバージョンを指定するためのファイルです。 Vite+では.node-versionを使うんですが、nvmを使っているプロジェクトには、.nvmrcが置かれていることがあります。 そこで、vp migrateで.nvmrcを見つけたら、.node-versionに移行できるようにしました。 vite-plus#1159 例えば、20.11.0のようにバージョン番号が書いてあれば、その値を移します。 先頭にvが付いていれば、それを取り除く、という感じです。 ここまでは、ちょっと整えてコピーするだけなんですけど、実は.nvmrcには、バージョン番号以外も書けるんですよね。 その指定をどう扱うか、というところで少し悩みました。 例えば、.nvmrcには、バージョン番号の代わりにnodeと書くことができます。 これは、Node.jsの最新リリースを使う、という指定です。 一方、lts/*と書くと、最新のLTSを使う指定になります。 この2つ、似ているんですけど、必ずしも同じバージョンにはならないんですよね。 なので、最初はnodeが指定されていたら、警告を出して移行を止めるようにしていました。 勝手にLTSに変換すると、使うNode.jsのバージョンが下がってしまう可能性があるので、それはちょっと違うかなと思ったんです。 ただ、PRを出したところ、レビューで「LTSに変換してもいいんじゃないか」という提案をもらいました。 vite-plus#1159 ちょうどその頃、Node.js 27以降は、すべてのメジャーバージョンがリリース後にLTSへ移行する、という発表も読んでいました。 nodejs.org そうしたことも踏まえて、最終的にはlts/*に変換して、移行を進める形にしました。 ただし、元の指定とは意味が変わるので、変換したことはログに出すようにしています。 この対応、最初は設定ファイルの中身を移すだけだと思っていたんですよね。 でも実際にやってみると、元の設定をそのまま移せないケースがありました。 今回も、私は元の設定の意味を変えないことを優先していたんですけど、レビューでは、移行を進められるようにするという別の考え方をもらいました。 どちらが正しいというより、Vite+としてどういう動作にするのがいいのか、考える必要があったんですね。 こういうふうに、コードを書く前後で、ほかのメンバーと方針を相談することも、OSSへの貢献の面白いところだなと思いました。 ここまでは、普段から馴染みのあるNode.js周りの話だったんですけど、次は少し違う領域に取り組んだ話です。 それが、Nushellのサポートです。 Nushellは、BashやZshと同じように、ターミナルでコマンドを実行するためのシェルです。 Vite+には、Node.jsのバージョンを切り替えるvp envという機能があって、これをNushellでも使えるようにする、というIssueでした。 vite-plus#1144 この部分はRustで書かれていたんですが、実際のプロダクトでRustを使うのは初めてでした。 なので、まずは既存のBashやFish向けの実装を読んで、どういう処理をしているのか調べるところから始めました。 わからない型や構文を調べながら、同じことをNushellではどう書けばいいのか、少しずつ確認していきました。 ただ、Rustのコードが読めれば終わりではなくて、出力するNushellのスクリプトについても調べる必要がありました。 例えば、こちらのコードです。 動かない source "$HOME/.vite-plus/env.nu" 動く source ~/.vite-plus/env.nu 上の例では、sourceに、$HOMEから始まるパスを渡しています。 Bashなどでは、ホームディレクトリを指定するときに、こういう書き方をしますよね。 ただ、Nushellでは、ダブルクォートの中の$HOMEは展開されません。環境変数の書き方も、$env.HOMEになります。 じゃあ、そこを書き換えればいいのかと思ったんですけど、実はそれでも動かなかったんですよね。 というのも、Nushellのsourceは、コマンドを実行する前の、解析の段階で読み込むファイルを決める仕組みになっています。 nushell.sh なので、実行時の環境変数を、そのままパスに使うことができません。 そこからNushellの仕様を調べ直して、下の例のように、チルダから始まるパスに修正しました。 これなら、解析の段階でホームディレクトリへのパスを解決できます。 vite-plus#1312 Rust側では文字列を作っているだけなんですけど、それがNushellでどう解釈されるかまで考えないといけなかったんですね。 なので、実際にNushellで動かしながら、確認していきました。 そもそも、Rustで実際のプロダクトのコードを書いた経験は、これまでありませんでした。 普段はフロントエンドエンジニアとして働いているので、仕事でRustを使う機会もないんですよね。 LeetCodeの問題をRustで解いたりはしていたんですけど、それくらいでした。 自分で勉強しているだけだと、どうしても知っている範囲でやりがちなんですけど、OSSだとそうはいきません。 直したい問題があれば、知らない言語や仕様でも、調べる必要があります。 今回も、Rustだけでなく、Nushellの仕様まで調べることになりました。 最初から全部わかっていたわけではなくて、調べて、試して、レビューで教えてもらって、少しずつ理解していった感じです。 それが自分の勉強にもなって、使っているツールへの貢献にもなるので、結構お得なんじゃないかなと思っています。 Core Team に入って そんな感じで、気になったIssueを調べたり、PRを出したりしていました。 そうしていたら、最初のPRから約1か月後に、Vite+のCore Teamに招待してもらったんですね。 これは、本当に驚きました。 OSSのCore Teamに参加するのは初めてでしたし、そこにいるのは、自分にとって雲の上の存在のようなエンジニアばかりだったので。 まさか自分が同じチームで開発することになるとは、思っていませんでした。 チームに入ってからは、自分でPRを出すだけでなく、ほかの人のIssueやPRも見るようになりました。 例えば、Issueが報告されたら、まず自分の環境でも再現するか試してみます。 再現できたら原因を調べたり、情報が足りなければ報告してくれた人に確認したりしています。 あとは、ほかの人のPRをレビューすることも増えました。 ただ、コードを見ただけでは、なぜその変更が必要なのかわからないこともあるんですよね。 なので、関連するIssueや過去のやり取りを読んだり、必要に応じてVite+以外のプロジェクトのコードまで調べたりしています。 ここからは、そうした活動の中で取り組んできたものを、いくつか紹介します。 まず紹介するのは、tsdownからVite+への移行で起きていた問題です。 tsdownは、TypeScriptのライブラリをビルドするためのツールです。 Vite+では、tsdownから移行できるようになっていたんですが、移行したあとにTypeScriptのエラーが出るケースがありました。 vite-plus#1500 調べてみると、tsdown/clientという型定義への参照が、移行後も残っていたんですね。 そこで、Vite+側に対応する参照先を用意して、vp migrateでも自動的に書き換えるようにしました。 vite-plus#1501 ただ、この参照はソースコードのimportだけでなく、型宣言やtsconfig.jsonなど、いろんな場所で使われていました。 vite-plus#1502 なので、それぞれの書き方に合わせて、移行処理を追加する必要がありました。 #1541 はimportとdeclare moduleを書き換えます。 #1542 はtsconfig.jsonのcompilerOptions.typesを書き換えます。 依存関係を置き換えるだけなら簡単そうなんですけど、実際には、移行したあともTypeScriptが正しく動くところまで考える必要があったんですね。 次は、CIの話です。 仕事でVite+を導入するなら、手元で動くだけではなく、CIでも使いたいですよね。 そこで取り組んだのが、setup-vpというツールです。 これは、CI環境にVite+をインストールしたり、依存関係やキャッシュを設定したりするためのツールです。 当時はGitHub Actionsには対応していたんですが、GitLab CIには対応していませんでした。 なので、GitLabでVite+を使おうとすると、インストール処理などを自分で書く必要があったんですね。 setup-vp#88 そこで、GitLab CIでも簡単にVite+を使えるように、テンプレートを追加しました。 setup-vp#97 今は私もsetup-vpのコラボレーターとして、継続的にメンテナンスに参加しています。 この対応では、いきなりコードを書き始めたわけではなくて、まず設計をRFCにまとめました。 github.com/voidzero-dev/setup-vp/blob/main/rfcs/g… RFCというのは、機能や設計の方針を提案して、ほかのメンバーと議論するための文書です。 今回は、GitLab CIでどう使うのか、どんな順番で処理するのかを、図と文章にまとめました。 GitHub Actions向けの実装がすでにあったので、最初はそれを流用すればよさそうに見えます。 ただ、GitLab CIでは、入力の受け取り方やPATHの設定方法などが違うので、そのままでは動きません。 そこで、使い方はできるだけ揃えつつ、GitLab向けの処理を用意しました。 その後も開発は続いていて、今ではインストールや認証などの処理を、複数のCIで共有する構成になっています。 キャッシュにも対応していて、GitHub ActionsとGitLab、それぞれのキャッシュ機能を使えるようになっています。 もちろん、今の構成を全部自分で作ったわけではありません。 私がGitLab対応を追加したあと、ほかのメンバーも機能を追加してくれました。 こうやって、一つのPRをきっかけに、ほかの人と一緒に機能が育っていくのも、OSSの面白いところだと思っています。 ここまでは、自分で実装したものを紹介してきましたが、チームに入ってからは、Issueの原因調査にも関わるようになりました。 その一つが、SolidStart v2でvp previewが失敗するというIssueです。 vite-plus#2416 Vite+を使っていてエラーが出ているので、最初はVite+側に問題があるようにも見えますよね。 ただ、これだけでは、どこが原因なのかはわかりません。 そこで、Vite+を使うプロジェクトと、Viteだけを使うプロジェクトの、2つを用意して試してみました。 Vite+で再現したリポジトリ Viteだけで再現したリポジトリ すると、Viteだけでも、同じエラーが出たんです。 つまり、少なくともVite+を使わなくても、問題が起きることはわかりました。 じゃあViteの問題なのかというと、それもまだわかりません。 SolidStart側の処理かもしれないので、スタックトレースを見ながら、どこで失敗しているのかを調べていきました。 さらに調べていくと、原因はSolidStartとNitroの連携部分にありました。 Nitroは、サーバー側のアプリケーションをビルドするためのツールです。 ビルドしたサーバーファイルを.output/serverに出力するんですが、SolidStart側では、別の場所を探していたんですね。 そのため、Nitroのpreview処理に進む前に、SolidStart側でエラーになっていました。 そこで、SolidStartのリポジトリにIssueを立てて、再現用のリポジトリと、調査した内容を共有しました。 solid-start#2291 その後、SolidStart側で修正してもらい、修正が含まれたバージョン2.0.1がリリースされました。 修正PR #2294 @solidjs/start 2.0.1 のリリース 自分でも更新してみて、問題が解消されたことを確認しています。 この対応では、私はコードを修正していません。 ただ、Vite+で報告された問題でも、Vite+で直すのが正しいとは限らないんですよね。 原因を調べて、適切なプロジェクトにつなぐことも、OSSへの貢献の一つだと思っています。 ここまで紹介してきたように、チームに入ってからは、自分でコードを書く以外にも、いろんな形でプロジェクトに関わるようになりました。 最初の頃は、自分が困っていた問題を直すことが中心でした。 例えば、最初のvp createのPRも、テンプレートが見つからないことを、わかりやすく表示できれば解決でした。 ただ、チームに入って、ほかの人のIssueやPRを見るようになると、コードを書く前に考えることが増えました。 SolidStartの件も、いきなりVite+側を修正していたら、原因とは違うところを触っていたかもしれません。 なので、まずは問題を調べて、どこで対応するのが正しいのかを考えるようになりました。 自分のPRをレビューしてもらう側から、ほかの人の提案についても、一緒に考える側になった。 そこが、最初の頃と大きく変わったところだと思っています。 AI と OSS への貢献 ここまで、Issueの調査やPRのレビューについて話してきました。 こうしたコードを読んだり、実装を進めたりするときには、私もAIを使っています。 特に、慣れていない言語を読むときには、かなり助けられました。 ただ、自分でAIを使ってPRを出すときと、チームでほかの人のPRを受け取るときでは、少し違うことも感じています。 ここからは、その両方の視点で感じたことを紹介します。 まずは、先ほどのNushell対応の話です。 Nushellの対応では、Rustのコードを読むためにAIを使っていました。 この型は何なのかとか、この構文はどういう意味なのかを、その都度聞いていました。 処理の流れを、HTMLのアニメーションにしてもらったこともあります。 慣れていない言語だと、構文がわからないだけで、なかなか先に進めないんですよね。 なので、その場で説明してもらえるのは、かなり助かりました。 ただ、AIの説明を読むと、なんとなくわかった気にもなるんです。 先ほどのNushellの例でも、Rust側の処理が理解できたとしても、出力されたsourceのコマンドが実際に動くかは、別の話です。 なので、実際にNushellで動かしたり、元のコードや仕様を調べたりして確認していました。 PRを出すと、レビューで、なぜこう書いたのかを聞かれることもあります。 そこで「AIがそう言っていたので」と答えても、説明にはならないですよね。 だからこそ、AIに教えてもらったことも、自分で確認して、自分の言葉で説明できるようにしています。 一方で、PRをレビューする側になって、感じることもあります。 最近は、Issueが立ってから5分もしないうちに、実装のPRが届くこともあるんですよね。 もちろん、早く修正してもらえるのはありがたいです。 ただ、Issueによっては、まだ対応するかどうかも決まっていないことがあります。 そこにPRが届くと、コードを確認するだけでなく、そもそもこの変更が必要なのか、というところから考える必要があります。 レビューで質問を返しても、返信がなくなってしまうこともあります。 そうなると、変更の意図を確認できないまま、PRが止まってしまいます。 AIを使えば、コードを書く時間は短くできます。 でも、そのコードを理解して、正しく動くか検証する時間まで、なくなるわけではありません。 そこをメンテナーに任せてしまうと、単に負担を移している だけになってしまうんですよね。 なので、AIを使うなら、コードを書く前の調査や理解にも使えるんじゃないかな、と思っています。 例えば、GitHubでOpenになっているIssueを見つけたとします。 でも、Openだからといって、必ずしも実装を待っているわけではありません。 まだ方針を議論していることもありますし、そもそも対応するかどうかも決まっていないかもしれません。 そこで、まずはIssueのやり取りをAIに整理してもらう。 元のコメントも確認しながら、何が決まっていて、何がまだ決まっていないのかを理解する、という使い方です。 それでもわからなければ、自分で調べたことを添えて、メンテナーに相談してみればいいと思います。 私もSolidStartのIssueでは、再現する条件や調査した内容を共有して、修正の方向性を相談しました。 AIを使えば、コードを書くこと自体は、以前よりずっと簡単になっています。 でも、大切なのはPRを出すこと自体ではなくて、問題を理解して、自分で検証し、その変更に責任を持つことだと思っています。 なので、いきなりコードを書いてもらうだけではなく、問題を理解するところからAIに手伝ってもらう。 そういう使い方も、OSSへの貢献では大切なんじゃないかなと思っています。 おわりに ここまで、私が取り組んできたIssueやPRを、いくつか紹介してきました。 最初は、vp createで自分が困ったところを直しただけだったんですけど、続けているうちに、移行処理やシェル、CIなど、いろんなところに関わるようになりました。 もちろん、どれも最初から詳しかったわけではありません。 わからないところを調べて、実際に試して、PRを出して、レビューでまた教えてもらう。その繰り返しでした。 そうしているうちに、Vite+のコードだけでなく、プロジェクトの中でどんな議論があって、どういう方針で開発されているのかも、少しずつわかるようになってきました。 今、ほかの人のIssueやPRを見るときにも、そのときに調べたことが役に立っています。 ここまで、コードの話を中心にしてきたんですけど、実は、コードを書かなくてもOSSに貢献できることはあります。 例えば、先ほどのSolidStartの件です。 私がやったのは、問題を再現して、原因を調べて、その内容をIssueで共有するところまででした。 実際のコードの修正は、別の人が進めてくれました。 ほかにも、Issueで報告された問題が、自分の環境でも再現するか試してみるだけでも助かります。 そのときに、使っているバージョンや再現手順が書いてあると、原因を調べやすくなるんですよね。 逆に、修正されたあとに「更新したら直りました」と報告してもらえるのも、ありがたいです。 あとは、ドキュメントを直したり、使ってみた感想を伝えたりすることも、立派な貢献だと思っています。 自分がIssueを調べたり、PRをレビューしたりするようになって、こういう報告のありがたさを実感するようになりました。 OSSに興味はあるけれど、自分にできることなんてあるのかな、と思っている方もいるかもしれません。 そういう方は、まず普段使っているツールで、気になったことを一つ調べてみるのがいいと思います。 例えば、何か問題に遭遇したら、GitHubで同じIssueがないか探してみる。 見つかったら、自分の環境でも再現するか試してみる。再現する条件がわかったら、それをコメントしてみる。 それだけでも、問題を調べているメンテナーにとっては、助けになることがあります。 もし実装してみたいものがあれば、まずはIssueのやり取りや、コントリビューションガイドを読んでみてください。 まだ方針が決まっていなければ、調べたことを伝えて、相談してみるのもいいと思います。 今はAIにも手伝ってもらえるので、知らないコードを調べたり、理解したりすることも、以前より取り組みやすくなっています。 私自身も、最初からCore Teamに入ろうと思っていたわけではありません。 自分が使っていて困ったところを調べて、修正を出した。それがきっかけで、今もVite+の開発に関わっています。 最後に、私がなぜOSSへの貢献を続けているのか、という話をしたいと思います。 自分が気になった問題を調べて、実際にコードを修正して、それが使っているツールの改善につながる。 それ自体も、もちろん面白いです。 でも、それだけではなくて、普段の仕事では関わる機会のないエンジニアと、同じプロジェクトについて議論したり、お互いのコードをレビューしたりできる。 そういう人とのつながりも、OSSを続けている大きな理由です。 最初は、自分が使っていて困ったところを直すことから始まりました。 今は、そこで出会った人たちと、一緒にVite+を作っています。 （ここから1番伝えたいところ） OSSは、コードだけではありません。 その先には、一緒に考えたり、作ったりする人たちがいます。 これからも、そんな人たちと一緒に、OSSを作っていきたいと思います。 ご清聴ありがとうございました。

@odan3240 やるまで知らなくてできるんだ！！となりました nvm-sh/nvm

Node 26 Becomes LTS on 28 October: Upgrade Guide from 24 and 22 Node.js 26 is scheduled to enter Long Term Support on 28 October 2026, eight days after Node 24 drops from Active LTS to Maintenance on 20 October, and it is supported through 30 April 2029.[[1]](#cite-1) Node 22 stays in Maintenance until 30 April 2027, and Node 20 has been end-of-life since 30 April 2026. As of 19 October the latest 26.x release is 26.12.0, shipped 14 October with V8 14.6 and npm 11.20.0[[2]](#cite-2). This post gives you the full schedule table from the official file, the changes in Node 26 that can actually break an upgrade, the exact commands for nvm, fnm, Volta, GitHub Actions and Docker, and a plain answer to whether you should move now or wait. Nothing here is true until the release team flips the switch, so every date below is the planned one. TL;DR - Node 26 becomes LTS on 28 October 2026 (planned). The schedule file lists no codename yet, so none is stated here. - Node 24 enters Maintenance on 20 October 2026 and reaches end-of-life on 30 April 2028. Staying on 24 is safe for production. - Node 22 is already in Maintenance and ends on 30 April 2027. It is the line that needs a plan first. - Node 20 is end-of-life since 30 April 2026 and gets no security fixes. - What bites in 26: removed http.Server.prototype.writeHeader(), removed legacy _stream_* modules, runtime deprecations for module.register(), and the removal of --experimental-transform-types. - Run your tests on 26 with --trace-deprecation this week; switch production after 28 October, not before. Node.js release schedule as of 19 October 2026 The Node.js Release working group publishes its schedule as a JSON file, and the README table in the same repository is generated from the same dates[[1]](#cite-1)[[3]](#cite-3). The table below is copied from that file. The README adds the caveat that dates are subject to change, and that the exact date of an LTS move is chosen no later than the first day of the month it happens in. | Line | Status on 19 Oct 2026 | First release | LTS start | Maintenance start | End-of-life | | --- | --- | --- | --- | --- | --- | | Node 20 (Iron) | End-of-life | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 | | Node 22 (Jod) | Maintenance LTS | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 | | Node 24 (Krypton) | Active LTS until 20 Oct | 2025-05-06 | 2025-10-28 | 2026-10-20 | 2028-04-30 | | Node 25 | End-of-life | 2025-10-15 | none (odd line) | none | 2026-06-01 | | Node 26 | Current | 2026-05-05 | 2026-10-28 | 2027-10-20 | 2029-04-30 | | Node 27 | Not released | alpha 2026-10-28, start 2027-04-22 | not listed | 2027-10-20 | 2030-04-30 | Two readings of that table matter. First, the working group says an even-numbered line stays in Active LTS for 12 months and then spends 18 months in Maintenance[[3]](#cite-3). Node 24 and 26 both fit that pattern: 28 October to 20 October is the 12 months, 20 October to 30 April the 18. Second, the Node 27 row carries no LTS date and no codename in the schedule file. The file does not say what that means for the odd/even rule, so check the file again before you plan anything around 27. What Maintenance means for Node 24 The README defines Maintenance as critical bug fixes and security updates, with new features added only at the release team's discretion, typically when they help migration to a later line[[3]](#cite-3). It does not mean abandoned. Node 24 will keep getting security releases for another 18 months. The practical difference is that you should stop expecting backports of new APIs, and you should treat the line as a place you are leaving, not a place you are settling. Why Node 22 is the line that needs a decision Node 22 has about six months of life left (30 April 2027). If you run it, the question is not whether to move but whether to go to 24 or straight to 26. Going to 24 buys you until April 2028. Going to 26 buys you until April 2029 and one fewer migration. The catch is that 26 has been out for five months as a Current release, and the changes in the next section apply to you in full. What changed in Node 26 that matters when you upgrade The 26.0.0 release notes, dated 5 May 2026, list the headline items as the Temporal API enabled by default, V8 updated to 14.6 and Undici updated to 8.0[[4]](#cite-4). Version numbers from the release feed: 26.12.0 ships V8 14.6.202.34 and npm 11.20.0, while Node 24.22.0 ships V8 13.6 and npm 11.19.1, and Node 22.23.3 ships V8 12.4 and npm 10.9.9[[2]](#cite-2). The npm major jump matters if you move from 22, because npm 10 to 11 is a separate set of changes to read. New in 26.0.0 - Temporal API on by default. The modern date and time API is available without a flag, contributed by Richard Lau in PR 61806[[4]](#cite-4). Your Date code keeps working. Nothing forces you to migrate, but libraries that feature-detect Temporal may change behavior once it exists. - V8 14.6. The notes call out Map.prototype.getOrInsert() and getOrInsertComputed() (also on WeakMap) plus Iterator.concat()[[4]](#cite-4). Both are small, but getOrInsertComputed removes the common get-check-set pattern in caches. - Undici 8.0.2 in the 26.0.0 release, which backs fetch. If you pin a custom undici dispatcher or agent, retest it. Removed and deprecated in 26.0.0 These are the entries that break builds, taken from the Deprecations and Removals section of the changelog[[4]](#cite-4): - http.Server.prototype.writeHeader() is gone. Use writeHead(). - The legacy _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform and _stream_passthrough modules are removed. Old packages that require('_stream_readable') will throw. Import from node:stream. - --experimental-transform-types is removed, which hits anyone running TypeScript files through that flag. - module.register() is now runtime-deprecated, so loader setups built on it print a warning. - DEP0182 moved to end-of-life, DEP0203 and DEP0204 became runtime deprecations in crypto, and DEP0201 in stream became a runtime deprecation. I did not look up what each DEP number covers in the deprecations page, so grep your warnings for those codes. - Platform floor: the build now needs GCC 13.2 and drops Python 3.9[[4]](#cite-4). That matters if you compile Node yourself or build native addons on old CI images. One more change that is easy to miss: localStorage now returns undefined when no storage file is configured, per the semver-major list in the same release[[4]](#cite-4). Code that assumed an object will fail at the first property access. Useful additions since 26.0.0 Node 26 already has twelve minor releases (26.1.0 to 26.12.0), so some features you may want are not in 24. These are the ones listed under Notable Changes, with the release that added them[[4]](#cite-4): | Version | Date | Addition | | --- | --- | --- | | 26.1.0 | 2026-05-07 | Experimental node:ffi module, behind --experimental-ffi | | 26.2.0 | 2026-05-20 | stream.compose marked stable; writeInformation for 1xx responses | | 26.8.0 | 2026-08-26 | TracingChannel in diagnostics_channel marked stable | | 26.9.0 | 2026-09-16 | node:ffi enabled by default | | 26.11.0 | 2026-10-07 | Buffer.stringLength(), isLatin1, Alpine Linux promoted to tier 2 support | | 26.12.0 | 2026-10-14 | http.websocketMask() and websocketUnmask() | The ffi row deserves a second look. The 26.1.0 notes say the API is inherently unsafe, since bad pointers or wrong signatures can crash the process or corrupt memory[[4]](#cite-4). Being on by default in 26.9.0 does not make it safe. Treat it as something you do not use in production code until it has a track record. Also from the notes: the 26.3.0 release flags a risk that macOS Universal Binaries may not be maintained for the full life of Node 26, though the stated intention is to keep shipping them as long as practical. Upgrade checklist: Node 24 or 22 to Node 26 1. Install 26 beside your current version Do not replace anything yet. Install 26 next to what you run, so you can switch per shell. # nvm: install, then carry global packages over from 24 nvm install --reinstall-packages-from=24 26 nvm use 26 # fnm fnm install 26 fnm use 26 # Volta (pins the version in package.json) volta install node@26 volta pin node@26 The --reinstall-packages-from flag is documented in the nvm README[[5]](#cite-5), and fnm install [VERSION] and fnm use [VERSION] are in the fnm command reference[[6]](#cite-6). The Volta commands are from memory of its docs and I did not re-verify them today, so run volta --help if one fails. After 28 October, nvm install --lts should resolve to 26, but check node -v rather than trusting it. 2. Declare what you support in package.json { "engines": { "node": ">=24 <27" } } Widening engines to cover both 24 and 26 lets you run both in CI during the transition without npm complaining. Add "engine-strict=true" to .npmrc if you want npm to enforce it. Also drop a .nvmrc or .node-version file: the actions/setup-node action reads either through its node-version-file input[[7]](#cite-7). If you use Corepack for package managers, run corepack --version after installing 26 to confirm it is present, because Corepack distribution has changed across recent Node releases and I did not trace the details. 3. Run a CI matrix on both lines jobs: test: runs-on: ubuntu-latest strategy: matrix: node: [24, 26] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v7 with: node-version: ${{ matrix.node }} - run: npm ci - run: npm test The current major of actions/setup-node is v7; its latest release, v7.1.0, was published on 8 October 2026[[7]](#cite-7). The README also notes that automatic package-manager caching is on by default and can be turned off with package-manager-cache: false for workflows that handle sensitive data. For a full pipeline around this step, see our [GitHub Actions CI/CD pipeline for Node.js](/blogs/github-actions-ci-cd-nodejs-complete-pipeline-2026). 4. Update Docker base images Docker Hub already carries the 26 tags: node:26, node:26-slim, node:26-alpine, node:26-bookworm-slim and node:26-trixie-slim, plus pinned forms like node:26.12.0[[8]](#cite-8). Pin a major (node:26-slim) in production, and pin the full version if you need byte-identical rebuilds. I could not confirm from a primary source whether Docker will add an lts alias pointing at 26 on 28 October, so do not depend on one. If your image builds native addons on Alpine, remember that 26.11.0 promoted Alpine to tier 2 support[[4]](#cite-4), which is good news but not a reason to skip a test build. Our [production Docker Compose guide for Node.js](/blogs/docker-compose-production-nodejs-redis-postgres-2026) covers the rest of the stack. How to test before you switch 1. Run the full suite on 26. Start with unit tests, then integration tests against real databases and queues. Failures from removed APIs show up as thrown errors, so they are loud. 2. Surface deprecations. Run node --trace-deprecation your-entry.js or set NODE_OPTIONS=--trace-deprecation in CI. Runtime deprecations print a warning with a stack, and the stack usually points at a dependency, not your code. To make the suite fail on them, use --throw-deprecation. 3. Grep for the removed names. Search your source and node_modules for writeHeader(, _stream_, module.register and experimental-transform-types. Dependencies are the usual source of old stream imports. 4. Rebuild native addons. Delete node_modules and run npm ci on 26 so every addon compiles against the new V8. Anything built with node-gyp needs a toolchain that supports GCC 13.2 on Linux; addons that ship prebuilt binaries need a release that targets Node 26's ABI. If a package has no 26 build, that is your blocker, not Node. 5. Diff your fixtures and configs. When a test fails on a data shape, normalize the sample before comparing. Paste it into the [JSON formatter](/tools/json-formatter) to normalize them before comparing, or run YAML configs through the [YAML to JSON converter](/tools/yaml-to-json-converter). 6. Soak in staging. Run 26 under real traffic in staging for a week and watch memory and latency. A new V8 changes garbage collection behavior in ways unit tests do not show. If your project is a command-line tool, our [Node.js and TypeScript CLI guide](/blogs/build-cli-tool-nodejs-typescript-complete-guide-2026) has patterns for testing across several runtime versions. When to upgrade now, and when to wait | Your situation | Recommendation | Reason | | --- | --- | --- | | Production on Node 20 | Move now, to 24 at minimum | End-of-life since 30 April 2026; no security fixes | | Production on Node 22 | Plan the move before spring 2027; test on 26 now | Ends 30 April 2027 | | Production on Node 24 | Wait. Test on 26, switch in 2027 | Supported until 30 April 2028 | | New project | Start on 24 today, or 26 after 28 October | 26 is the longer runway (to April 2029) | | Library author | Add 26 to your CI matrix now | Users will adopt 26 as soon as it is LTS | The reason to wait on 24 is boring and sound: LTS lines get fixes that have been audited by the release team, and a Current line that has just changed status has had less production exposure than the fifth month of a stable one. Node 26 has had five months of Current releases, and the 26.3.1 and 26.5.1 releases each shipped a list of CVE fixes[[4]](#cite-4). Active patching counts in its favor, though it also shows the line has had real security work to do. If you do move before the LTS date, treat it as a normal Current-line adoption: pin an exact version, watch the changelog for each minor, and be ready to roll back. Frequently asked questions What date does Node 26 become LTS? The official schedule file lists 28 October 2026 as the LTS start for Node 26[[1]](#cite-1). The README says dates are subject to change, so confirm on the day. This post was written on 19 October, before that date. Is Node 24 still safe to use after 20 October? Yes. From 20 October 2026 it is in Maintenance, which means critical bug fixes and security updates, until 30 April 2028[[1]](#cite-1). You lose new-feature backports, not security fixes. When does Node 22 reach end-of-life? 30 April 2027, according to the schedule file[[1]](#cite-1). It has been in Maintenance since 21 October 2025. Is Node 20 end-of-life already? Yes. The schedule lists 30 April 2026 as its end date[[1]](#cite-1). If you still run it, upgrade to 24 or 26 rather than hunting for patched builds. Does Node 26 have a codename? Not in the schedule file as of 19 October 2026, where the codename field for v26 is empty[[1]](#cite-1). Earlier LTS lines got element names such as Jod and Krypton, but I will not guess one for 26. Can I skip Node 24 and go from 22 straight to 26? Yes, and many teams will. You inherit every removal and deprecation between the two lines, plus the npm 10 to 11 change, so read the changelogs for 24 and 26 and run the test steps above. I only reviewed the 26 changelog for this post. Sources 1. nodejs/Release: schedule.json (read 19 October 2026) 2. Node.js release feed, nodejs.org/dist/index.json (read 19 October 2026) 3. nodejs/Release README: release schedule and phases (read 19 October 2026) 4. Node.js 26 changelog, CHANGELOG_V26.md (read 19 October 2026) 5. nvm README: installing and --reinstall-packages-from 6. fnm command reference 7. actions/setup-node README and releases (v7.1.0, 8 October 2026) 8. Docker Hub: official node image tags (read 19 October 2026) --- Originally published at wowhow.cloud

NodeSchool Learn on your own --- title: NodeSchool Learn on your own published: true published_at: 2026-10-17 13:00 +0000 tags: javascript, nodejs, tutorial canonical_url: khriztianmoreno.dev --- When it comes to learning a new technology or understanding the features of a language, we always look for tutorials on the internet that teach us its concepts. That's why today I want to talk to you about nodeschool.io, an initiative that aims to teach these topics through self-guided workshops. <!--more--> Node School is a community that helps you gain skills in Node.js and JavaScript in an interactive format. All their tutorials are Open Source and start with simple exercises that gradually increase in difficulty as you progress. To complete the Node School modules, you should have an intermediate knowledge of JavaScript. Otherwise, I recommend reading a couple of tutorials or doing the javascripting workshop that you can find within Node School. When you feel comfortable with the language, you will be ready to start. Getting Started with Node School !Dashboard Learnyounode workshop To start with the workshops provided by Node School, you need to have Node.JS installed on your computer. You can download the installers from their official page and follow the wizard (personally, I like to install Node via NVM). The lessons run in the terminal and work on Linux, Mac, and Windows. Let's see how to work with these lessons. Installing a Lesson or Workshop It is recommended to create a directory on your computer with the name of the workshop and access it from the terminal. Then we will install the workshop via NPM. $ mkdir learnyounode $ cd learnyounode $ npm install -g learnyounode $ learnyounode After running the learnyounode command, we will have a list of exercises to complete in the console. Let's see now how to work on these exercises in the best way. Completing an Exercise When we select an exercise, in this case, "Hello World," we will have a screen similar to the one shown below, where we will see the exercise description and some tips and resources to learn more about the content. !Exercise ‘Hello World’ The exercise recommends creating a file with a .js extension (I particularly like to name this file with the name of the exercise). In this case, I will create a file called helloworld.js where we will write the solution. To verify that our solution to the exercise is correct, we must run the command learnyounode verify helloworld.js. $ touch helloworld.js $ learnyounode verify helloworld.js If our solution is correct, Node School will indicate it with a similar screen. If it fails, it will tell us where we went wrong. !learnyounode verify progrma.js Finally, if we run the learnyounode command again, Node School will indicate that we have completed the previous exercise. !learnyounode verify progrma.js I hope this short guide helps you start your self-learning journey. Until next time. I hope this has been useful and/or taught you something new! !Profile @khriztianmoreno 🚀

Node.jsのversion、projectを移るたび手で切り替えていませんか？ nvmはPOSIX shell向けNode.js version manager。`.nvmrc`を置くと`nvm use`や`nvm install`がversion指定を読みます。macOS/Linux/WSL対応で、native Windows/Fishは対象外。 nvm-sh/nvm

The NVM Project: You've Never Seen Code Grow Like This! 🌱 See the Node Version Manager repository come to life, visualizing 88 commits by 22 developers in just 11 months. What open-source project should we visualize next? 🔗 Repo: nvm-sh/nvm ⭐ 95,536 stars 🎨 Visualized with Gource 🎵 Music: "Avs_Silvester - Search the Right Path (lobit on Pancho Guitar) (AMRR01)" by Avs_Silvester & Shine Lethargy & ulguma & Vlad Shegal — CC0 — archive.org #NVM #Nodejs #OpenSource #Gource #GitHub

nvm makes Node version drift a solvable operating problem. Use it to standardise dev environments. Verdict: boring infrastructure that prevents expensive noise. Source: nvm-sh/nvm. KLI ships reliable systems. What version mismatch cost you this month?