package.jsonのチルダ（〜）とキャレット（^）の違いは何ですか？

私は、最新の安定にアップグレードした後nodeとnpm、私が試してみましたnpm install moment --save。エントリをpackage.jsonキャレット^プレフィックス付きで保存します。以前は、チルダ~プレフィックスでした。

1. なぜこれらの変更は行われるのnpmですか？
2. チルダ~とキャレットの違いは何^ですか？
3. 他より優れている点は何ですか？

NPMのドキュメントとsemverのドキュメントをご覧ください。

• 〜version「バージョンとほぼ同等」は、マイナーバージョンを増分せずに、将来のすべてのパッチバージョンに更新します。~1.2.31.2.3から<1.3.0までのリリースを使用します。

• ^ version「バージョンと互換性がある」は、メジャーバージョンを増分せずに、将来のすべてのマイナー/パッチバージョンに更新します。^2.3.42.3.4から<3.0.0までのリリースを使用します。

以下のコメントを参照してください。

質問で言及されているものを含む、バージョンの特定のためのすべての方法を説明する公式のnpmjsドキュメントも追加したいと思います-

https://docs.npmjs.com/files/package.json

https://docs.npmjs.com/misc/semver#x-ranges-12x-1x-12-

• ~version「バージョンとほぼ同等」npm semver- Tilde Ranges＆semver（7）を参照
• ^version「バージョンとの互換性」npm semver- Caret Ranges＆semver（7）を参照
• version バージョンと正確に一致する必要があります
• >version バージョンより大きい必要があります
• >=version 等
• <version
• <=version
• 1.2.x 1.2.0、1.2.1など。ただし1.3.0は不可
• http://sometarballurl （これはローカルにダウンロードおよびインストールされるtarballのURLである可能性があります
• * すべてのバージョンに一致
• latest 最新のリリースを取得

上記のリストは完全なものではありません。その他のバージョン指定子には、GitHubのURLとGitHubのユーザーリポジトリ、ローカルパス、特定のnpmタグ付きのパッケージなどがあります。

npmを使用すると、指定したバージョンよりも新しいバージョンのパッケージをインストールできます。チルダ（~）を使用するとバグ修正リリースが提供され、キャレット（^）を使用すると下位互換性のある新機能も提供されます。

問題は、通常、古いバージョンはそれほどバグ修正を受け取らないため、npmはの^デフォルトとしてキャレット（）を使用します--save。

によると：「Semver説明-なぜ私のpackage.jsonにキャレット（^）があるのですか？」。

ルールは1.0.0以上のバージョンに適用され、すべてのプロジェクトがセマンティックバージョニングに従うわけではないことに注意してください。バージョン0.xxの場合、キャレットはパッチの更新のみを許可します。つまり、チルドと同じように動作します。「キャレットレンジ」を参照

概念の視覚的な説明は次のとおりです。

出典：「セマンティックバージョニングチートシート」。

セムバー

<major>.<minor>.<patch>-beta.<beta> == 1.2.3-beta.2

• npm semver計算機を使用するテストにはを。（^（同じメジャー範囲の特定のバージョンより大きいすべてを含む）および〜（同じマイナー範囲の特定のバージョンより大きいすべてを含む）の説明は100％正しくありませんが、計算機は正常に動作しているようです）
• または、代わりにSemVer Checkを使用します。これは、パッケージを選択する必要がなく、説明も提供します。

変更を許可または禁止する

• ピンのバージョン：1.2.3。
• 使用^（頭のような）。左から2番目のゼロ以外のレベルでの更新を許可します：を^0.2.3意味し0.2.3 <= v < 0.3ます。
• ~（尾のように）使用します。通常、右端のレベルをフリーズするか、省略した場合はゼロに設定します。
  • ~1 手段 1.0.0 <= v < 2.0.0
  • ~1.2を意味し1.2.0 <= v < 1.3.0ます。
  • ~1.2.4を意味し1.2.4 <= v < 1.3.0ます。
• 右端のレベルを省略：0.2はを意味し0.2 <= v < 1ます。以下とは異なり~ます：
  • 省略レベルバージョンの開始は常に 0
  • サブレベルを指定せずに、メジャーバージョンの開始を設定できます。

すべての（うまくいけば）可能性

メジャーレベルの開始を設定し、上方への更新を許可する

*  or "(empty string)   any version
1                         v >= 1

メジャーレベルをフリーズ

~0 (0)            0.0 <= v < 1
0.2               0.2 <= v < 1          // Can't do that with ^ or ~ 
~1 (1, ^1)        1 <= v < 2
^1.2              1.2 <= v < 2
^1.2.3            1.2.3 <= v < 2
^1.2.3-beta.4     1.2.3-beta.4 <= v < 2

マイナーレベルをフリーズ

^0.0 (0.0)        0 <= v < 0.1
~0.2              0.2 <= v < 0.3
~1.2              1.2 <= v < 1.3
~0.2.3 (^0.2.3)   0.2.3 <= v < 0.3
~1.2.3            1.2.3 <= v < 1.3

パッチレベルを凍結

~1.2.3-beta.4     1.2.3-beta.4 <= v < 1.2.4 (only beta or pr allowed)
^0.0.3-beta       0.0.3-beta.0 <= v < 0.0.4 or 0.0.3-pr.0 <= v < 0.0.4 (only beta or pr allowed)
^0.0.3-beta.4     0.0.3-beta.4 <= v < 0.0.4 or 0.0.3-pr.4 <= v < 0.0.4 (only beta or pr allowed)

更新を許可しない

1.2.3             1.2.3
^0.0.3 (0.0.3)    0.0.3

通知：メジャー、マイナー、パッチの欠落、またはbeta番号なしの指定anyは、欠落レベルの場合と同じです。

注意：0メジャーレベルのパッケージをインストールすると、更新プログラムは新しいベータ/ prレベルのバージョンのみをインストールします！これnpmは^、がデフォルトとして設定されpackage.json、インストールされたバージョンがのよう0.1.3になっている場合、すべてのメジャー/マイナー/パッチレベルがフリーズするためです。

• https://docs.npmjs.com/misc/semver
• https://docs.npmjs.com/files/package.json#dependencies

~メジャー番号とマイナー番号を修正しました。依存関係のバグ修正を受け入れる準備ができているが、互換性のない可能性のある変更を望まない場合に使用されます。

^メジャー番号のみを修正します。依存関係を注意深く監視していて、マイナーリリースに互換性がない場合にコードをすばやく変更する準備ができている場合に使用されます。

それに加えて、^されたサポートされていません古いNPMのバージョンによって、注意して使用する必要があります。

したがって、これ^は適切なデフォルトですが、完全ではありません。あなたにとって最も役立つsemverオペレーターを注意深く選択して構成することをお勧めします。

~：合理的に近いと

   ~1.1.5: 1.1.0 <= accepted < 1.2.0

^：互換性を持ちます

   ^1.1.5: 1.1.5 <= accepted < 2.0.0

   ^0.1.3: 0.1.3 <= accepted < 0.2.0

   ^0.0.4: 0.0.4 <= accepted < 0.1.0

^is 1. [any]。[any]（最新のマイナーバージョン）
~は1.2。[any]（最新のパッチ）

よく読んでいるのは、 semverがnpmにどのように適用される
か、およびsemver標準に一致させるために彼らが何をしているのかについてのこのブログ投稿です。http ：//blog.npmjs.org/post/98131109725/npm-2-0-0

帽子のマッチングはに更新さ^0.1.2れないため、「壊れている」と見なされ0.2.0ます。ソフトウェアが出現している場合、0.x.yバージョンを使用し、ハットマッチングは最後の変化する数字（y）にのみ一致します。これは意図的に行われます。その理由は、ソフトウェアがAPIを急速に進化させている間、ある日にはこれらのメソッドがあり、別の日にはこれらのメソッドがあり、古いものはなくなっているからです。すでにライブラリを使用している人のためにコードを壊したくない場合は、メジャーバージョンをインクリメントします（例：1.0.0-> 2.0.0->）3.0.0。したがって、ソフトウェアが最終的に100％完成し、フル機能を備えた時点で、バージョンのように11.0.0なり、あまり意味がなく、実際には混乱しているように見えます。もしそうなら、一方で、0.1.x->0.2.x-> 0.3.xバージョンその後、ソフトウェアが最終的に100％完了し、フル機能を備えた時点で、バージョンとしてリリースされ1.0.0ます。つまり、「このリリースは長期的なサービスであり、このバージョンのライブラリを続行して本番環境で使用できます。コード、そして著者は明日または来月すべてを変更することはなく、パッケージを放棄することはありません。」

ルールは次のとおりです。0.x.yソフトウェアがまだ成熟していない場合はバージョン管理を使用し、公開APIが変更された場合は中央の桁を増やしてリリースします（したがって、人々は更新を^0.1.0取得0.2.0せず、コードを壊しません）。次に、ソフトウェアが成熟したら、それをリリースし1.0.0、パブリックAPIが変更されるたびに左端の桁を増やします（そのため、人々は更新を^1.0.0取得2.0.0せず、コードを壊しません）。

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

〜チルダ：

• ~メジャー番号とマイナー番号をフリーズします。
• 依存関係のバグ修正を受け入れる準備ができているが、互換性のない可能性のある変更を望まない場合に使用されます。
• チルドは最新のマイナーバージョン（中央の数字）と一致します。
• 〜1.2.3はすべての1.2.xバージョンに一致しますが、1.3.0には対応しません。
• チルダ（〜）はバグ修正リリースを提供します

^キャレット：

• ^ メジャー番号のみをフリーズします。
• 依存関係を注意深く監視していて、マイナーリリースに互換性がない場合にコードをすばやく変更する準備ができている場合に使用されます。
• 最新のメジャーバージョン（最初の番号）に更新されます。
• ^ 1.2.3は、1.3.0を含むすべての1.xxリリースと一致しますが、2.0.0には対応しません。
• キャレット（^）は、下位互換性のある新しい機能も提供します。

Tilde〜はマイナーバージョンと一致します。1.4.2が含まれるパッケージをインストールしていて、インストール後、package.jsonで〜1.4.2として使用し、npm installを実行すると、バージョン1.4.3および1.4.4も使用できますアップグレード後のプロジェクトでは、プロジェクトに1.4.4がインストールされます。しかし、そのパッケージで利用可能な1.5.0がある場合、それは〜によってインストールされません。マイナーバージョンと呼ばれます。

キャレット^はメジャーバージョンに一致します。プロジェクトに1.4.2パッケージがインストールされていて、インストール1.5.0がリリースされた後、^はメジャーバージョンをインストールします。^ 1.4.2がある場合、2.1.0をインストールできません。

固定バージョン特殊文字アウトと各インストール上のパッケージの変更バージョンにしたくない場合は、次に使用される固定バージョン例えば「1.4.2」

最新バージョン*最新バージョンをインストールする場合は、パッケージ名の前に*のみを使用してください。

ワンライナー解説

標準のバージョン管理システムは、major.minor.buildです（例2.4.1）。

npmは、これらの文字に基づいて特定のパッケージのバージョンをチェックして修正します

〜：メジャーバージョンが修正され、マイナーバージョンが修正され、任意のビルド番号に一致します

例：〜2.4.1は、2.4.xをチェックすることを意味します。

^：メジャーバージョンは修正され、任意のマイナーバージョンに一致し、任意のビルド番号に一致します

例：^ 2.4.1は、2.xxをチェックすることを意味します。

おそらく、package.jsonのチルダ（〜）とキャレット（^）を見たことがあるでしょう。それらの違いは何ですか？

npm install moment --saveを実行すると、エントリがpackage.jsonにキャレット（^）プレフィックス付きで保存されます。

チルダ（〜）

簡単に言うと、ティルダ（〜）は最新のマイナーバージョン（中央の数字）と一致します。〜1.2.3はすべての1.2.xバージョンに一致しますが、1.3.0には対応しません。

キャレット（^）

一方、キャレット（^）はよりリラックスしています。最新のメジャーバージョン（最初の番号）に更新されます。^ 1.2.3は、1.3.0を含むすべての1.xxリリースと一致しますが、2.0.0には対応しません。

リファレンス：https : //medium.com/@Hardy2151/caret-and-tilde-in-package-json-57f1cbbe347b

semverは、ドットで区切られた3つの主要セクションに分かれています。

major.minor.patch
1.0.0

これらの異なるメジャー、マイナー、およびパッチは、異なるリリースを識別するために使用しています。タイド（〜）とキャレット（^）は、パッケージのバージョン管理で使用するマイナーバージョンとパッチバージョンを識別するために使用しています。

~1.0.1
 Install 1.0.1 or **latest patch versions** such as 1.0.2 ,1.0.5
^1.0.1
 Install 1.0.1 or **latest patch and minor versions** such as 1.0.2 ,1.1.0 ,1.1.1

チルダ（〜）

メジャーバージョンは修正済み、マイナーバージョンは修正済み、任意のビルド番号に一致

"express": "~4.13.3" 

~4.13.3 4.13.xをチェックすることを意味します。ここで、xは何でもあり、4.14.0です。

キャレット（^）

メジャーバージョンは修正され、マイナーバージョンと一致し、ビルド番号と一致します

"supertest": "^3.0.0"

^3.0.0 3.xxをチェックすることを意味します。

バージョン番号は、各セクションを異なる意味で指定する構文になっています。構文は、ドットで区切られた3つのセクションに分かれています。

major.minor.patch 1.0.2

メジャー、マイナー、およびパッチは、パッケージの異なるリリースを表します。

npmは、チルド（〜）とキャレット（^）を使用して、それぞれ使用するパッチとマイナーバージョンを指定します。

したがって、〜1.0.2と表示されている場合は、バージョン1.0.2または1.0.4などの最新のパッチバージョンをインストールすることを意味します。^ 1.0.2が表示されている場合は、バージョン1.0.2または最新のマイナーバージョンまたは1.1.0などのパッチバージョンをインストールすることを意味します。

カラットに ^は、同じメジャー範囲の特定のバージョンよりも大きいすべてが含まれます。

チルダに ~は、同じマイナー範囲内の特定のバージョンよりも大きいすべてが含まれます。

たとえば、1.0.4までの許容可能なバージョン範囲を指定するには、次の構文を使用します。

• パッチリリース：1.0または1.0.xまたは〜1.0.4
• マイナーリリース：1または1.xまたは^ 1.0.4
• メジャーリリース：*またはx

セマンティックバージョニング構文の詳細については、npm semver計算機を参照してください。

npmドキュメントの詳細セマンティックバージョニングについて

それ自体は答えではなく、見落とされているように見える所見です。

カラット範囲の説明：

参照してください：https : //github.com/npm/node-semver#caret-ranges-123-025-004

[major、minor、patch]タプルの左端のゼロ以外の数字を変更しない変更を許可します。

^10.2.3一致する手段10.2.3 <= v < 20.0.0

それが彼らの意味だとは思わない。バージョン11.xxから19.xxを取り込むと、コードが破損します。

彼らが意味したと思うleft most non-zero number field。SemVerには、数値フィールドを1桁にする必要があるものはありません。

〜マイナーバージョンリリースの仕様^メジャーバージョンリリースを指定

たとえば、パッケージのバージョンが4.5.2の場合、アップデート時に〜4.5.2は最新の4.5.xバージョン（マイナーバージョン）をインストールします^ 4.5.2は最新の4.xxバージョン（メジャーバージョン）をインストールします

この質問に関連して、バージョンに関するComposerのドキュメントを確認できますが、ここでは簡単に説明します。

• チルダバージョン範囲（〜）-〜1.2.3は> = 1.2.3 < 1.3.0と同等
• キャレットのバージョン範囲（^）-〜1.2.3は> = 1.2.3 < 2.0.0と同等

したがって、Tildeを使用すると、パッチの自動更新が行われますが、マイナーバージョンとメジャーバージョンは更新されません。ただし、Caretを使用する場合は、パッチとマイナーバージョンを取得しますが、メジャー（重大な変更）バージョンは取得しません。

ティルデバージョンは「安全な」アプローチと見なされますが、信頼性の高い依存関係（よく管理されたライブラリ）を使用している場合は、キャレットバージョンに問題はありません（マイナーな変更によって変更が破壊されることはないためです）。

composer installとcomposer updateの違いについては、おそらくこのStackoverflowの投稿を確認する必要があります。