node.jsのnpmモジュールバージョン管理

2746 ワード
version nodejs npm
semver
npmのモジュールのバージョンはすべて従う必要があります. semver 2.0 の意味化バージョン規則を発表しました.
バージョンのフォーマット:メインバージョン番号.サブバージョン番号.修正番号、バージョン番号は下記の通りにインクリメントされます.メインバージョン番号:互換性のないAPIを修正したとき、次のバージョン番号:下の互換性のある機能が追加されたとき、修正番号:下の互換性の問題を修正したとき.先行バージョン番号とバージョンコンパイル情報は、「メインバージョン番号.サブバージョン番号.リビジョン番号」の後に追加されます.
そして、意味化されたバージョンに基づいて、バージョンを選択する際に、依存性をバージョン制御することができる.
dependencies: { "express": "3.x", "debug": "*", "express-session": "~1.0.0", "connect-redis": "1.2.3" }
例から見れば、バージョンの範囲を選択するスタイルがたくさんあります. semver in npm にはそれぞれ違ったスタイルの役割が見られます.node.jsのモジュール管理の中で、最もよく使われているのはいくつかです.
  • *:任意のバージョン
  • 1.1.0:指定バージョン
  • ~1.1.0: >=1.1.0&&<1.2.0
  • ^1.1.0: >=1.1.0&&<2..0
    • そのうち ~ 和 ^ 二つのプレフィックスは人を迷わせ、簡単に言えば:
  • ~ プレフィックスは、指定されたこのバージョンより大きくインストールされ、マッチします. x.y.z にある z 最新バージョン
  •  プレフィックス ^0.y.z 時の表現と ~0.y.z 同じですが、しかし ^1.y.z の場合は、合致します. y 和 z 全部最新バージョンです.
  • は、バージョン番号が ^0.0.z または ~0.0.z に際して 0.0.z 不安定なバージョンですので、それらは同じです. =0.0.z
    • semverの弊害
    semverの仕様によると:
  • の全てのbreaking changeはメインバージョン番号をアップグレードする必要があります.
  • 後方互換の追加機能は、サブバージョン番号のみをアップグレードすることができます.
    • しかし、最終的に実践の過程で、多くのカバンがこの原則に従わなかったり、この原則を破壊したことに気づかなかったりして、
  • 機能が追加され、breaking change
    • をもたらしました.
  • 既存のバグを修復し、未知のbreking changeを導入する
    • .
    これによって次の話題が出てきました.モジュール依存範囲をどのように正しく選択するかということです.
    依存範囲の選択方法
    nodeモジュール
    nodeのモジュールを編纂する時、モジュール自身はいくつかのdependenciesに依存するかもしれませんが、私達は毎回依存するモジュールに小さいbug fixがあると思わないです. ~ プレフィックスは、これらの依存モジュールのbug fixを楽しむことができ、自身のバージョンを更新する必要がないことを保証することができる.同時に、いくつかのAPIの変更による予期せぬエラーも導入されない.もちろん、信頼されているモジュールがあれば、使用も考えられます. ^ 接頭辞
    see: コア
    nodeプロジェクト
    しかし、nodeのプロジェクトを作成する時、私達は更にすべての依存するいかなる変動まで追跡することができることを望んで、プロジェクトも自身のバージョンの更新の悩みに関してあることはできないため、死に依存するバージョンを書く傾向があります.
    see: koa-todo
    モジュールのバージョンをどう選択しますか?
    編纂過程の中でどのように依存範囲を選択しますか?振り返ってみます.もしnpmに発表されたモジュールを編纂したいなら、どうやって発表されたモジュールのバージョンを選ぶべきですか?
  • このモジュールの開発を開始したばかりの場合、その機能とAPIは大きな調整がある場合、リリースを選択することができます. 0.0.z バージョン
  • で、一つのモジュールのAPIは基本的に成形されているが、いくつかの新しいAPIが増加する可能性がある場合、リリースを選択することができる. 0.y.z バージョン
  • モジュールの機能がほぼ完全に決まった時、リリースを選択することができます. x.y.z(x>=1)バージョンです.モジュールがnpmにリリースされると、正式に準備されているという意味ですので、リリースの最初のバージョンはなるべく 1.0.0です
  • 小さいバグを修復したら、アップグレードしてください. z のバージョン番号を使用して、ユーザーを通過させることができます. ~ 和 ^ プレフィックスは最速であなたのbug fixを楽しむことができます.
  • 新しい機能が追加されたら、アップグレードを選択できます. y のバージョン番号です
  • 変更が元のインターフェースに影響を与える場合、最低でもアップグレードします. y のバージョン番号は、このライブラリに依存するほとんどのユーザに影響を与えません.
  • モジュールを再構築した場合、設計から大きく異なる場合、アップグレードが必要です. x バージョン番号
    • このいくつかの規則に従って、ユーザーはこのモジュールを導入する時に、簡単にsemverによって提供された検証メカニズムによって、あなたのモジュールをより簡単に使用することができます.
    NodeJSでは複雑なデータ構造を管理します.