議論: Node.jsのバージョン管理方針

Node.js専用のバージョン管理ツールの導入の是非

背景としては下記:

https://github.com/chirimen-oh/chirimen/issues/109#issuecomment-893166495 より:

Node.js は npm パッケージ n を使うより APT リポジトリ NodeSource を使うほうが管理の単純さの点でメリットがあると考える n そのものを動かすためのランタイムの Node.js に加えて n によって管理される Node.js の少なくとも 2 つをメンテナンスする必要があるが、NodeSource を使いAPTリポジトリに統一することによってその必要が無くなる
curl -sL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs
https://github.com/nodesource/distributions#installation-instructions

https://github.com/chirimen-oh/chirimen/pull/111#discussion_r684139354 より:

@WhiteHawk-taka これだと LTS のメジャーバージョンが上がった際に自動的に最新版が入ってしまいそうです。本来は LTS では動くとよいですが 14.x のように不具合が発生しても困るので、明示的に 14.x を設定したほうがよいかと思いますがいかがでしょうか。もしくはやはり n や XXenv のようにバージョン管理ツールでの管理のほうが後々 apt でのアップデートに依存せずバージョンを自由に選択できるようになるため利用者に有益かと思います。

@kou029w https://deb.nodesource.com/setup_lts.x を見てもらうと分かりますが利用者の端末にはこのコマンド実行時点でのメジャーバージョンのNode.jsリポジトリが導入されます。したがってご懸念のように意図しないバージョンアップによる不都合は生じにくいかと考えます。

@kou029w もし仮にバージョンを固定するのであれば、APTコマンドで行うことも可能と考えます。APTはDebian系ディストリビューションで標準的に使われているバージョン管理ツールです。

@kou029w もし仮にバージョンを柔軟に変更したいというユースケースが有益ということであれば、ご指摘のように何かしらNode.js専用のバージョン管理ツールを使うほうがよいとも考えます。

@kou029w バージョンの差異による不都合を防ぐという観点では、もし仮にn等バージョン管理ツールを使ったとしても利用者がそのバージョン管理ツールによってシステム内のNode.jsのバージョンに変更すると同様の不都合は起こりうるのではないでしょうか。この懸念事項に関する私の提案としてはAPTコマンドの他にpkgによってランタイムごと実行ファイルとして提供するのが望ましいのではないかとも考えます。Issueを立て対応したほうがよいでしょうか? バージョンを柔軟に変更したいというユースケースについては私には判断つかないです。これは前述のランタイムのバージョンの差異に起因する不都合とのトレードオフがあるかと思います。

@WhiteHawk-taka 確認ありがとうございます。

https://deb.nodesource.com/setup_lts.x を見てもらうと分かりますが利用者の端末にはこのコマンド実行時点でのメジャーバージョンのNode.jsリポジトリが導入されます。したがってご懸念のように意図しないバージョンアップによる不都合は生じにくいかと考えます。

確かにこれだと現在 LTS のバージョンが（現在であれば 14.x 系が）入りそうです。あまり確認せず失礼しました。それであれば明示的に 14.x としたほうが setup.sh を流して試行する際に、バージョンが明確で意図的にバージョンが上げれてよいかと思います。ただ、マイナーバージョンを前後させる需要はあまりないと思いますが、メジャーバージョンのアップデートの需要はあると思います。（主にフロントエンドツールや TS 的に） chirimen のツールが Node のバージョンアップに耐えられるか心配なので固定 + 任意のバージョンへの容易な変更があったほうがよいと思います。可能であれば他の方の意見も聞きたいです。

それ (メンテナーによる setup.sh 実行時点でのアクティブLTSのリポジトリが導入される) であれば明示的に 14.x としたほうが setup.sh を流して試行する際に、バージョンが明確で意図的にバージョンが上げれてよいかと思います

https://deb.nodesource.com/setup_14.x などではなく https://deb.nodesource.com/setup_lts.x と指定することはメンテナンスの単純さの点で優位と私は考えます。これに関してはいかがですか。 > @WhiteHawk-taka

またメジャーバージョンを柔軟に変更したいというユースケースについては、バージョンの差異に起因する不都合とのトレードオフがあると私は考えており、少なくともメンテナー以外のエンドユーザーのnode srv.jsのプロセスについてはバージョンを変更させない状態で提供するのが望ましいと考えます。バージョンの差異に起因する不都合の解決策として、私の提案としては下記の2点のいずれかです。

APTコマンドによるバージョンの固定
pkgによってランタイムごと実行ファイルとして提供

これらに関してはいかがですか。 > @WhiteHawk-taka

起票ありがとうございます。

https://deb.nodesource.com/setup_14.x などではなく https://deb.nodesource.com/setup_lts.x と指定することはメンテナンスの単純さの点で優位と私は考えます。これに関してはいかがですか。

おっしゃるとおり setup.sh のメンテナンスの点では優位かと思います。
ただし、そのイメージが作成されたときの node のバージョンがコード上でパッと見たときに不明になる点・将来的に LTS が 16系になったときコミュニティ的に即時に setup.sh の検証ができない点を考慮すると 14.x としたほうが良さそうに思います。

またメジャーバージョンを柔軟に変更したいというユースケースについては、バージョンの差異に起因する不都合とのトレードオフがあると私は考えており、少なくともメンテナー以外のエンドユーザーのnode srv.jsのプロセスについてはバージョンを変更させない状態で提供するのが望ましいと考えます。

はい、この点について基本的には私も同意です。
しかし、バージョンを変更したいユーザーもいるかと思いますので、変更の方法を予め提示できたほうがエンドユーザーが意図的にバージョンを変更した際に戻すことが楽という利点があるかと思います。ご提案いただいた方法の中では私は 1 のほうがよいかと思います。

ご回答ありがとうございます。

たしかにコミニュティ内での混乱を避ける目的で https://deb.nodesource.com/setup_14.x 等メジャーバージョンを明示したほうが良さそうですね。そうしましょう。

システム内のNode.jsのバージョンの固定については apt-mark hold を使用しましょう。

バージョンの変更手段については確かに従来nを使用している利用者もいる気がするのでシステム内にインストールし提供したほうが良さそうですね。そうしましょう。

chirimen-oh / chirimen

議論: Node.jsのバージョン管理方針 #112