前回の依存を、全員のパソコンでそろえる
前回のF-08では、npmで他人のコードをパッケージとして取り込み、その依存が芋づる式に連鎖することを見ました。今回は、その依存を誰のパソコンでも同じ構成に再現するための、2つのファイルを学びます。B-10で触れた「バージョンが違うと動かない」という問題に対する、実務上の答えがここにあります。単なる設定ファイルではなく、環境をそろえる土台として位置づけてください。
このスライドのポイント
- F-08: npmで他人のコードをパッケージとして取り込み、依存が連鎖することを見た
- 今回: その依存を、誰のパソコンでも同じ構成に再現するための2ファイル
- B-10の「バージョンが違うと動かない」問題への実務的な答え
package.jsonとlockfileの定義
まず言葉を定義します。package.jsonは、プロジェクトの台帳となるファイルです。プロジェクトの名前、頼っているパッケージとそのバージョンの範囲、そして実行コマンド、いわゆるscriptsを記録します。一方のlockfileは、実際にインストールされた全パッケージの正確なバージョンを、固定して記録したファイルです。ここには、直接入れたものだけでなく、F-08で見た芋づる式の間接依存も含まれます。この2つがそろえば、別のパソコンでも同じ構成を再現できます。
このスライドのポイント
- package.json＝プロジェクトの台帳ファイル。名前・依存パッケージとバージョンの範囲・実行コマンド（scripts）を記録
- lockfile＝実際にインストールされた全パッケージの正確なバージョンを固定記録したファイル
- lockfileには、直接入れたものだけでなく間接依存も含まれる
- この2つがあれば、別のパソコンでも同じ構成を再現できる
知らないと起きること
この2つを知らないと、「自分のパソコンでは動くのに、他の人のパソコンでは動かない」という、B-06やB-10で見た問題の主な原因が読めません。多くの場合、その正体は、入っているパッケージのバージョンが微妙に違うことにあります。さらに、lockfileを消す、あるいは無視するといった危険な操作をAIが提案しても、なぜ危険なのかに気づけません。再現性を守る土台が、この2つのファイルなのです。
このスライドのポイント
- 「自分のパソコンでは動くのに、他の人のパソコンで動かない」（B-06・B-10）の主要因が読めない
- 多くの場合、正体は入っているパッケージのバージョンが微妙に違うこと
- lockfileを消す・無視するというAIの提案の危険性に気づけない
意図と事実の2層構造
全体像を、意図と事実の2層で整理します。package.jsonは「この範囲のバージョンであればよい」という意図を書いたものです。そこにインストールという操作が加わると、lockfileが生まれ、「実際にこれが入った」という事実を固定します。意図だけでは、入るバージョンが人によってずれる余地が残ります。事実を固定するlockfileがあって、初めて再現性が完成します。この2層の分離が、今回の要点です。
このスライドのポイント
- package.json＝「この範囲のバージョンでよい」という意図
- インストールという操作を経て、lockfile＝「実際にこれが入った」という事実が生まれる
- 意図だけでは、入るバージョンが人によってずれる余地が残る
- 事実を固定するlockfileがあって、初めて再現性が完成する
チーム開発・新しいPCへの引っ越し
具体例で見ます。チームで開発するときや、新しいパソコンへ引っ越すとき、この2つのファイルとインストール1回で、同じ環境がそろいます。逆に、package.jsonだけを共有してlockfileを共有しないと、どうなるでしょうか。各自のインストールのタイミングで微妙に違うバージョンが入り、「私の環境では動く」という問題が再発します。lockfileは、その食い違いを防ぐために、共有すべきファイルなのです。
このスライドのポイント
- 2つのファイルとインストール1回で、同じ環境がそろう
- package.jsonだけ共有しlockfileを共有しないと、微妙に違うバージョンが入る
- その結果、「私の環境では動く」問題が再発する
- lockfileは共有すべきファイル
サンプルカード: package.jsonを読む
サンプルを見ます。種別はconfig、目的はpackage.jsonの各部分を読み分けることです。dependenciesが直接依存の一覧、scriptsが定型コマンドの置き場です。そして、キャレット付きの1.2.0のような表記は、「この範囲なら可」という意図の表明であり、確定版はlockfileが持ちます。AIには「このpackage.jsonのscriptsには何があり、それぞれ何をしますか」と聞いて、実行される中身を先に説明させると安全です。
意図と事実は別物
混同しやすいのは、package.jsonとlockfileの役割です。package.jsonは意図であり、許容するバージョンの範囲を書きます。lockfileは事実であり、実際に入ったバージョンを固定します。前者だけでは、入るものが人によって変わりうるため、再現性は完全ではありません。範囲と固定、この2つはセットで初めて働く、と覚えてください。
このスライドのポイント
- package.json（意図・範囲）vs lockfile（事実・固定）
- package.jsonだけでは、入るものが人により変わりうる
- 範囲と固定、この2つはセットで初めて働く
バイブコーディングでの確認点
確認すべき点です。AIがlockfileの削除や作り直しを提案してきたら、一段立ち止まってください。これは入る依存が変わりうる操作であり、A-09で分類した中から高リスクにあたります。実行する前に、なぜ必要なのか、何が変わるのかをAIに説明させ、人間が判断します。質問例としては「lockfileを作り直すと、どのパッケージのバージョンが変わりますか」が有効です。理由の説明がないまま消すのは避けます。
このスライドのポイント
- AIがlockfileの削除・作り直しを提案したら一段止まる
- 依存が変わる操作＝A-09の中〜高リスク
- 「なぜ必要か・何が変わるか」を説明させてから人間が判断
まとめと次回
最後に一問一答です。実際に入った全依存の、正確なバージョンを記録するファイルは何でしょうか。少し考えてみてください。答えは、lockfileです。package.jsonは範囲を示す意図、lockfileはそれを固定した事実、と対で覚えてください。30秒でまとめます。package.jsonは台帳、lockfileは再現性の要。この2つで、環境が誰のパソコンでもそろいます。次回はカテゴリF最終回、実行する前に誤りを見つけるTypeScriptへ進みます。関連資料は「Git・GitHub 完全入門」と「アプリ運用チェックリスト」です。
このスライドのポイント
- 一問一答: 実際に入った全依存の正確なバージョンを記録するのは？ → lockfile
- 30秒まとめ: package.jsonは台帳（意図・範囲）、lockfileは再現性の要（事実・固定）
- 次回: カテゴリF最終回、実行前に誤りを見つけるTypeScriptへ
- 関連資料: 「Git・GitHub 完全入門」「アプリ運用チェックリスト」
