0.y.z は「作っている途中」
最初の数が 0 の間は、いつ何が変わってもよい、という決まりです。0.3 から 0.4 に上がるだけで、使い方が変わることがあります。
部品の入れ方（Composer と npm）
PHP の部品は Composer で、JavaScript の部品は npm で入れます。道具は違っても、形はほとんど同じです。
何のためかComposer（PHP）npm（JavaScript）
この場面で打つのは？
場面を押すと、Composer と npm のコマンドが出ます。
版の番号の読み方
多くの部品は「セマンティック バージョニング」という決まりで、版の番号を 3 つの数で付けます。どの数が上がったかで、どのくらい変わったのかが分かります。
Laravel の場合
Laravel もこの決まりに沿っていて、大きな版は毎年 1 回出ます。小さな版には互換性のない変更を入れない、としています。そのため Laravel は、^13.0 のような範囲で書くよう勧めています。
決まりは、約束にすぎない 考え方のヒント
番号の付け方を決めるのは、部品の作者です。PATCH でも動きが変わってしまうことはあります。だから lock ファイルで版を止め、上げるときはテストで確かめます。
範囲の書き方（^ と ~）
composer.json や package.json には、ふつう「この範囲なら入れてよい」と書きます。下の計算機で書き方を試すと、例の部品のどの版が入るかが分かります。同じ書き方でも、Composer と npm で意味が違うものがあります。
例の部品が出している版（作り物）。✓ は範囲に入る版、入る版 はその中でいちばん新しい版
この計算機は、1.2.3 のような数だけの版を扱います。1.0.0-beta のようなプレリリースの版と、1.0 - 2.0 のようなハイフンの書き方は扱いません。
lock ファイル
範囲で書くと、入れた日によって入る版が変わってしまいます。そこで、実際に入れた版を lock ファイルに書き残し、Git にコミットします。すると、同僚も CI も本番も、同じ版で動きます。
install と update のちがい
composer install は、lock がある限り、lock の版をそのまま入れます。composer update は、範囲の中で新しい版を選び直して、lock を書き換えます。lock を書き換えるのは、上げたいときだけです。
npm ci は、lock を書き換えない
npm ci は lock がないと動かず、lock と package.json が食い違っていればエラーで止まります。node_modules を消してから入れ直し、package.json も lock も書き換えません。CI や本番に向いています。
lock ファイルがぶつかったら
2 つのブランチで部品を足すと、マージで composer.lock がぶつかります。lock は文字を合わせるだけでは正しくなりません。Composer の文書がいちばん安全とする方法は、片方のブランチのファイルを取り、もう片方の変更（composer require など）をやり直すことです。最後に composer validate で確かめます。
アップデートの進め方
部品は、放っておくとどんどん古くなります。古いほど、上げるときに一度に変わる所が増えます。小さく、こまめに上げるのが楽です。考え方のヒント
手伝ってくれる仕組み
Dependabot の設定の例（Composer と npm を毎週）
弱点（脆弱性）の知らせへの向き合い方は、セキュリティ「古い部品・サプライチェーン攻撃」へ。
サポート期限（EOL）
PHP・Laravel・Node.js には、直してもらえる期限があります。期限が切れた版は、弱点が見つかっても直りません。期限の前に、上げる計画を立てます。
うちの組み合わせは大丈夫？
AI 時代AI と部品
AI は部品を選ぶのも、使い方を書くのも速いです。けれど、版の違いには弱いことがあります。
チェックリスト
できているものに印を付けてください（この端末にだけ残ります）。考え方のヒント