Yarn: 競合するロックファイルは貧弱なUXを作成します

package.jsonに構成を追加して、

engineフィールドの良いユースケースになる可能性があります🤔

ラウンドトリップpackage-lock.json → yarn.lock → package-lock.jsonは損失がありますが、それはおそらく重要ではありません。 yarn.lock → package-lock.json → yarn.lockは損失がないはずです、AFAIK。

npm視点、私は場合はオプション賛成yarn見package-lock.jsonしていないyarn.lock 、それをインポートし、削除されることにpackage-lock.json 。 同様に、 npm yarn.lockれ、 package-lock.jsonが表示されない場合も同じように、 `yarn.lockをインポートして削除します。

これにより、両方のツールのユーザーは、ユーザーのプロジェクトを混乱させた状態（ファイルが両方からのものであるように見える）のままにすることなく、シームレスに前後に切り替えることができます。

package-lock.jsonもyarn.lockもファイルにメタデータを追加できず（Yarnは現在追加できませんが、なぜそうではないのか）、一部を削除することを意味するため、私はこれに少し懸念を抱いていますその過程で私たちのフォーマットに自由を。

この問題は、もともと別のスレッドで議論し、一般的に糸とNPMの間の相互運用性の問題を提起する-私も相互運用できるようにしようとするように感じるユーザーは、その後、すべてがまったく同じように動作することを期待を持っているでしょうから、私達の両方に値するかもしれません両方のプロジェクトで、これは危険な仮定だと思います（1つの明白な例は、誰かがワークスペースを利用したプロジェクトでnpmを実行すると、ワークスペースがサイレントに壊れることです）。

@ yarnpkg / core、考え？

両方のツールを1つのロックファイルからに移行させる@iarnaのアイデアが好きです
自動的にインストールする別の。
回避するために、移行後にインポートされたロックファイルを削除することは理にかなっています
1つのプロジェクトで両方のパッケージマネージャーが競争します。

どちらのツールも警告を出力し、続行するようにユーザープロンプトを要求する可能性があります。

100％の互換性を達成するとロックされるというMaelの主張にも同意します
新しい機能を探求することから、私たちはそれを一回限りのものとして扱うべきだと思います
移行パス、それは私たちのinstall.jsのかなり小さな機能である可能性があります
側。

9：49 PM MAEL二尊院のでは水、2018年4月11日に[email protected]書きました：

私はこれに少し心配しています、なぜならそれはどちらも意味しないからです
package-lock.jsonもyarn.lockも、ファイルにメタデータを追加できるようになります
（糸は現在そうではありませんが、なぜそうではありません）、私たちのフォーマットにいくつかの自由を取り除きます
過程の中で。

この問題はまた、ヤーンとの間の相互運用性の問題を提起します
npm全般、元々は別のスレッドで議論されていました-試してみたいと思います
相互運用性が高すぎると、ユーザーがそうするので、私たちの両方に値するかもしれません
すべてが両方でまったく同じように機能することを期待しています
私が感じるプロジェクトは危険な仮定です（1つの明白な例は
誰かがnpmを実行すると、そのワークスペースはサイレントに壊れます
ワークスペースを利用したプロジェクト）。

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core 、考え？

—
あなたは言及されたチームに所属しているので、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
。

数週間前に「他のロックファイルを変換する」ソリューションの実装に関心を示したため、 送信します。 彼は今ではいくつかの実用的なコードさえ持っているかもしれません。

pingをありがとう！

そうです、私は実際にまさにこれに取り組んでいる最中です。 私は来週、ヤーンRFCを作成し、すべての利害関係者にpingを送信することを計画していました。

簡単に言うと、yarn.lock <==> package-lock.jsonの変換についていくつかの作業を行いました。 プロセスにはいくつかの損失がありますが、論理的なものはほとんどありません。 私の目には、上記の「1回限りの変換」シナリオについて話している場合、これは完全に受け入れられます。 これについてさらに議論したい場合は、さらに詳しく説明します。

私は現在これを行ういくつかの基本的なコードを持っています： https ：
これは100％ではなく、変換するプロジェクトを既存および現在のnode_modulesフォルダーに依存します。 レジストリからパッケージの状態を取得する（ブランチ2.0.0 ）再書き込みの最終段階にあります（すばらしいpacote libを使用）。

それが終わったら私がやりたいのは、これをyarnとnpm両方に正確に実装したい方法（そしてもしそうなら）について話し始めることです。

これについてみんなの考えを聞いてみたいです。

私の目には、上記の「1回限りの変換」シナリオについて話している場合、これは完全に受け入れられます。

それほど一般的ではないと思います。 私は間違っているかもしれませんが、より一般的なユースケースはYarnを使用するプロジェクトであり、開発者の1人がREADMEからコマンドをコピーして貼り付け、 yarn代わりにnpmを使用して依存関係を追加しyarn 。

このコンテキストでは、データを失い、正しいことをしようとしてパッケージレイアウトをサイレントに変更することが良いことだとはまだ確信していません。おそらく、問題が発生するまで気付かないでしょう（確認プロンプトが表示される可能性がありますが、これらのコマンドをコピーして貼り付ける人は、インストールプロンプトも盲目的に確認することを期待しています）。 さらに悪いことに、それは自分のマシンで動作する可能性がありますが、Yarnに戻ると、同僚のマシンで機能しなくなります。

@ arcanis-すべてのシナリオとエッジケースについて議論する価値があると思います。 あなたがおっしゃったシナリオでは、私は非常に同意しますが、1つのロックファイルに対して明確なバイアスが必要なシナリオは他にもあると思います。

この機能は、主にCI環境で使用されていると思います。そこでは、（OPが述べたように）輝けると思います。 少なくとも、両方のツールが他のツールのロックファイルを認識している必要があると思いますか？ 彼らが変換を行うことを決定したときの詳細を彼らに任せます。 どう思いますか？

この機能は、主にCI環境で使用されていると思います。そこでは、（OPが述べたように）輝けると思います。

例はありますか？ CIシステムは非常に決定論的な方法で動作することになっています。変換されたロックファイルを誤ってコミットすることは、PR時のimoでさらに悪化するはずですが、CIはこれには遅すぎます。

少なくとも、両方のツールが他のツールのロックファイルを認識している必要があると思いますか？

多分。 engineバージョンを使用して特定のパッケージマネージャーを強制すると、どちらのプロジェクトも排他的エンジンのリストを保持する必要があります（「yarn」は「npm」では満たすことができず、逆も同様です）。

私の考えでは、ロックファイルをその場で変換することもあまりスケーラブルではありません。 たとえば、これまではpackage-lock.jsonファイルについてのみ話していましたが、pnpmにはshrinkwrap.yamlという独自のロックファイルがあると思います。 それらの両方と、1つの石を思い付く可能性のある他の形式に対処する方法を見つけることができれば素晴らしいと思います。

この機能は、主にCI環境で使用されていると思います。そこでは、（OPが述べたように）輝けると思います。

また、私が正しく理解していれば、npmは現在CI固有の非常に軽いパッケージマネージャーに取り組んでいます。これは、ロックファイルコンバーターなどの重いビジネスロジックを必要とするものではうまく機能しない可能性があります。

CIについて：
私の最初の考えは次のとおりでした：反対のツールで新しいパッケージを追加するときに警告し、フレッシュインストールを行うときに変換します（またはより保守的に：フレッシュインストールでデフォルトで失敗し、 importコマンドまたは構成フラグを介して冗長に変換を許可しますインストール用）。

以前にnpm / yarnが混在する環境で作業していたときは、基本的にgit履歴を使用して手動でこれを行いました。 それは骨の折れるプロセスでした、そして私たちはこれで一人ではなかったと確信しています。

スケーラビリティに関して：
これについても説明したいと思います。
変換が実行されると、中間の論理および物理パッケージツリー（ロックファイルにある場合）が作成されます。 目的のロックファイルに変換するとき、それらのツリーが使用されます（または、 yarnから変換していて、物理ツリーがない場合は、適切なデフォルトで作成されます）。
このようにして、他のロックファイルタイプ間で簡単に変換できます（各タイプの論理/物理ツリーとの間の変換を提供するだけです）。

これは明らかに現在のツールの機能よりも少し進んでいますが、これを実装することは大きな問題ではないと思います。

（npmの新しいciツールに関しては-私はあなたが何を意味するのかわかりますが、これは現在の議論より少し進んでいると思いますか？）

またはより保守的に：新規インストールではデフォルトで失敗し、インポートコマンドによる変換を詳細に許可します

はい、私は完全にこの変換ロジックをyarn importコマンドに追加することになります。Yarnプラグインを実装する場合は、別のパッケージに抽出できる便利な機能のようです:)私のコメントは採用すべきデフォルトの動作に焦点を当てます。

npm@6時点で、最初にインストールを実行しなくても、 package-lock.json -> yarn.lockロスレスで変換できるはずです。 必要なすべてのデータ、識​​別子などが含まれている必要があります（npm @ 6のpkglockのrequiresフィールドには、 yarn.lock使用するものと一致するバージョン範囲がありますか？）

ああ、これが当てはまる前にhttps://github.com/yarnpkg/yarn/pull/5042も出荷する必要がありsha1がないためです。ケース。

@ arcanis-素晴らしい！ だからPRは：

1. package-lock.jsonファイルをインストールして見つけるときの警告
2. package-lock.jsonファイルを追加および検索する際の警告
3. importコマンドを使用してpackage-lock.jsonから変換する機能を追加します（その後、ファイルを削除します）
   受け入れられますか？ （詳細についての会話を開始するために使用できるものがあるので）

@ zkat-それはnpm@6について素晴らしいです！ それが私次第である場合、すべてのロックファイルバージョンをサポートするために、それを使用してマニフェストファイルにフォールバックすることを選択します。 npmに対して、同様の（または多少異なる）動作を実装してもよいかどうか尋ねてもらえますか？

また、私が正しく理解していれば、npmは現在CI固有の非常に軽いパッケージマネージャーに取り組んでいます。これは、ロックファイルコンバーターなどの重いビジネスロジックを必要とするものではうまく機能しない可能性があります。

「現在作業中」とは「出荷済み」を意味する場合は、はい。 =）

あなたが示唆しているように、現在yarn.locksをロードすることはその範囲を超えています（パッケージツリーをレイアウトする方法がわからないため）が、私たち全員がそのレイアウトを実行できるライブラリになってしまった場合、ロードをサポートすることに反対していません糸。ロック。 （理想的には、これはYarnとの間で共有されるライブラリになります。）明らかに、その場合、既存のロックファイルを削除するべきではありません。 パッケージのメタデータに関する限り、これは純粋に読み取り専用です。

package-lock.jsonファイルをインストールして見つけるときの警告

サポートされていない種類のロックファイルが存在するときに警告を表示するだけでは、Herokuが抱えている@jmorrellによって発生する問題に心配しています。

サポートされていない種類のロックファイルが存在するときに警告を表示するだけでは、Herokuが抱えている@jmorrellによって発生する問題に心配しています。

警告は改善されますが、適切なメッセージングを伴うエラーは、ユーザーimoにとって理想的です。 私は自分自身でしか話すことができませんが、yarnを使用するプロジェクトとnpmを使用するプロジェクトがいくつかあり、そのプロジェクトに間違ったプロジェクトを入力することがよくあります。 クイックエラーは、最初から持っているはずのものをすぐに使用できることを意味します。

警告の場合は、大きくて明白なはずです。 IMEユーザーは、パッケージマネージャーの出力が機能する限り、それを無視することを期待するようにかなり訓練されています。

私は、初心者の開発者との経験が豊富な人に連絡を取りました。彼らは、始めたばかりの人にとって、その経験がどのように見えるかについて話してくれることを願っています。

CIシステムは非常に決定論的な方法で動作することになっています。変換されたロックファイルを誤ってコミットすることは、PR時のimoでさらに悪化するはずですが、CIはこれには遅すぎます。

同意する。 理想的には、ビルド/ CIサービスに到達するまでに、アプリケーションは不確定な状態ではありません。 この場合、ビルドに失敗しないように私が安心できる唯一の方法は、ユーザーが自分の好みをpackage.jsonで示すための受け入れられた方法がある場合でしたが、そのソリューションはユーザーにより多くの負担をかけます。

サポートされていない種類のロックファイルが存在するときに警告を表示するだけでは、Herokuが抱えている@jmorrellによって発生する問題に心配しています。

実際にHerokuをプッシュする前に、ユーザーがおそらくやりたくないことをしていることをユーザーに警告することで、ユーザーを支援します。 実際にどれだけ数値が変わるかは

警告を提案する人への正直な質問： package-lock.jsonが存在するときにyarn installまたはyarn addを実行することは間違いではないという状況はありますか？ npm installとyarn.lock同上

npmからYarnへの移行、またはYarnからnpmへの移行が思い浮かびます。 他のパッケージマネージャーを試してみたいときは、摩擦を加えないようにしたいと思います。

また、警告とエラーは相互に排他的ではないこと、または少なくともengineフィールドではそうではないことも覚えておく必要があります。 パッケージマネージャーが固定されていないプロジェクトは警告を出力し、パッケージマネージャーが固定されているプロジェクトはエラーになる可能性があります。 このようにして、ユーザーは、選択を行い、それに応じてpackage.jsonを構成するまで、1つのパッケージマネージャーから別のパッケージマネージャーに自由に切り替えることができます。

エンジンフィールドのもう1つの利点は、どのバージョンのパッケージマネージャーを使用する必要があるかを確実に知ることができることです。 どこかで設定できると思いますが、このシステムでは通常のワークフローの一部になります。

エンジンフィールドのもう1つの利点は、どのバージョンのパッケージマネージャーを使用する必要があるかを確実に知ることができることです。 どこかで設定できると思いますが、このシステムでは通常のワークフローの一部になります。

engineフィールドはありますか、それともenginesを参照していますか？ engineを参照しているドキュメントが見つかりません。 何かが足りない場合はお詫びします。

enginesフィールドでのバージョンの指定をサポートしています： https ：

例：

  "engines": {
    "npm": "5.6.x"
  }

これを使用して、使用するパッケージマネージャーを決定することに関して、いくつかの懸念事項があります。

• 今日の状況：自明ではない数のユーザーがnpmとyarn両方、またはnpmバージョンを定義していますが、 yarn.lockます。 npmおよびyarn将来のバージョンではこれが強制される可能性がありますが、頻繁にアップグレードしないユーザーは、現在のバージョンを長期間使用し続けます。

• ほとんどのユーザーは、この構成に触れることはありません。 彼らは、nodejs.orgからダウンロードしたものを自分のマシンで使用しているにもかかわらず、ノード0.10を指定する古いボイラープレートをフォークしました。 これにより、Herokuで重要な数の問題が発生します。

• 多くの場合、チームはインストールしたバージョンを調整しません。 インストールしたNode、npm、yarnのバージョンは、多くの場合、プロジェクトを開始したとき、または最後にいずれかが壊れて再インストールを余儀なくされたときの最新のものです。 これが理想的というわけではありませんが、私の理解では、npm /ヤーンユーザーの大多数は初心者であり、これは開始に新たなハードルを追加します。

例：「サンプルのhello-worldプロジェクトのクローンを作成し、 https： //nodejs.orgからNodeをダウンロードしましたが、機能しませんでした」

そうは言っても、ツールが厳密なバージョンを適用し、それをengines記録してくれれば、私は大好きです。 それは私が毎日目にするエラーの多くを防ぐでしょうが、それははるかに大きな変化のように感じます。

そうは言っても、ツールが厳密なバージョンを適用してエンジンに記録した場合、私は大好きです。 それは私が毎日目にするエラーの多くを防ぐでしょうが、それははるかに大きな変化のように感じます。

AFAIK Yarnは、フラグを渡して無効にしない限り、このフィールドを厳密に適用します。

多くの場合、チームはインストールしたバージョンを調整しません。 インストールしたNode、npm、yarnのバージョンは、多くの場合、プロジェクトを開始したとき、または最後にいずれかが壊れて再インストールを余儀なくされたときの最新のものです。

これは、Yarnの同じメジャーバージョン間での一貫性のみを保証するため、特にYarnを使用する場合は非常に危険です。

これが理想的というわけではありませんが、私の理解では、npm /ヤーンユーザーの大多数は初心者であり、これは開始に新たなハードルを追加します。

Yarn（およびアイデアが気に入った場合はnpm）がenginesフィールドに"yarn": "^<current_version>"エントリを追加して、摩擦をあまりかけずに安全性を導入できるようにするのはどうですか？ yarn init 、 yarn importを実行するとき、またはロックファイルを最初から作成するときに、これを自動的に追加できます。

Yarnについてはよくわかりませんが、 package-lock.jsonパーサーをYarnに追加し、 yarn.lockが存在する場合は作成しないのが最善の解決策だと思います。

最終的な目標は、Yarnとnpmの間で1つのロックファイル形式を共有することだと思います。

@thatlittlegit https://github.com/yarnpkg/yarn/pull/5745について知っていただければ

追加のために編集：単一のロックファイル形式は、ロックファイル形式間にさまざまなトレードオフがあり、どれが最適かについてのコンセンサスがないため、起こりそうな結果ではないと思います。 両方のツールが互いのロックファイルを相互に理解できるようにすることで十分だと思います。

それ以外にも、ユーザーのユースケースを単一の一般的なソリューションよりも適切に満たすことができるため、さまざまなトレードオフを行う複数のアクティブに使用されるツールを使用することには多くの利点があります。

@BYKエンジンフィールドの動作に関するいくつかの履歴は、おそらくここで役立ちます。

で1 @ NPMとNPM @ 2 、我々は持っていたpackage.jsonと呼ばれるengineStrictに加えて、 engineフィールド。 engineStrictがtrueの場合、エンジンフィールドは_resolution制約_として使用され、バージョンのリストにsemver範囲を適用する前に、互換性のないエンジンを持つバージョンが除外されていました。 これにより、プラットフォームで[email protected]がサポートされていない場合、 [email protected]が公開されていても、 npm install fooようなことができ、 [email protected] npm install fooを取得できます。 これは望ましいと思われますが、実際には非常に混乱していました。特に、Webサイトのドキュメントは最新バージョンのみであったためです。

engineStrictがfalseの場合、エンジンフィールドに関係なく解決が行われ、結果に互換性がない場合は警告が発行されました。

engine-strictオプションもありました。これはpackage.jsonプロパティと同じことを行いましたが、すべてのパッケージに適用しました。

npm @ 3以降、 engineStrict package.jsonプロパティのサポートを終了し、 engine-strictオプションの動作を変更しました。 configオプションは、オフにしたときに発生する警告をエラーに変えるようになりましたが、解決には影響しません。

engineフィールドは、トップレベルのプロジェクトだけでなく推移的に適用されます。 yarnエンジンフラグを導入すると、依存関係はyarnでのみインストールできることを意味しますが、ここではそうではないと思います。

次のyarnリリースでは、 package-lock.jsonをyarn.lockにインポートできるようになるはずなので、警告/エラーの問題の説明に戻りたいと思います。

私の見方：単一のパッケージにpackage-lock.jsonとyarn.lock両方のファイルがあるのには十分な理由はないと思います。 私が見たほとんどのプロジェクトは、これを故意に、望ましい状況ではなく修正が必要な問題と見なしています（ただし、もちろん修正の余地はあります）。
上記の@iarnaの説明から理解できるように、 engineフィールドは、パッケージが使用しているパッケージマネージャーを明示的に指定するための適切なソリューションではありません。
つまり、IMO、これは、ユーザーに1つのファイルを削除するか、それを変換するように促す詳細なエラーを生成するはずの状況です。

しかし、そのようなエラーを生み出すことは明らかな重大な変化になると思います。 ヤーン側では、（上記のように）警告から始めて、エラーに変更される次のメジャーバージョン（おそらく両方のファイルを許可する構成フラグを追加する）まで、この動作を徐々に非推奨にすることを提案します同時に存在します）。

みんなどう思いますか？ @ jmorrell 、 @ BYK 、 @ arcanis 、@ iarna？

どのような種類のプロジェクトでも、使用するパッケージ管理ツールを指定する必要があるのは奇妙に思えます。 私が間違っている場合は訂正してください。ただし、Yarnは、主にエンドユーザーの好みに依存するドロップインの代替品と見なしています。 Yarnは事実上の標準としてNPMを完全に置き換えようとしていますか、それとも共存しようとしていますか？

@BrainBacon全員が同じロックyarn.lockあり、誰かがnpm installを実行した場合でも、その人は異なる依存関係のセットになってしまう可能性があります。 残念ながら、エンドユーザーの好みには依存しません。できれば、プロジェクトの全員が同じパッケージマネージャーを使用することをお勧めします。

これは、プロジェクトに2つのロックファイルを含めることは意味がないことも意味します。 それらが同じ依存関係ツリーに解決される可能性は低く、どのパッケージマネージャーを使用するかを寄稿者に不明確にします。

（ドロップイン置換部分は、npmがロックファイルを生成しなかった場合に特に当てはまりました。そこで失われる情報がなかったためです。＃5745が実際にYarnがpackage-lock.json基づいてロックファイルを生成できることを意味する場合も当てはまります。

私が間違っている場合は訂正してください。ただし、Yarnは、主にエンドユーザーの好みに依存するドロップインの代替品と見なしています。

ヤーンは、公開されたAPIの観点から、真っ直ぐなドロップインの代替品ではありません。 yarn add <pkg>とnpm install <pkg>は、私たちが別の方法で行うことの明らかな例です。 私たちは同じ機能セットを持っている傾向がありますが、最終的には2つの異なるツールであり、同じ問題に対して異なる解決策がある場合があります。

yarn.lockとpackage-lock.jsonはそれらの違いの1つであり、Yarnもnpmも異なる情報を含んでいるため、単一のものを使用することに興味がないと思います。

糸の側では、警告から始めることを提案します（上記のように）

これで大丈夫です。 何かのようなもの：

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

誰かがPRを開きたいですか？

警告を追加するPRを開いていただければ幸いです:)

package-lock.jsonが存在する+ yarn import場合、ここで必要な最終ソリューションは有用なエラーですか？ 私の理解では、 @ iarnaは、反対のロックファイルを削除/変換する必要があると主張していました。

どちらの解決策もユーザーにとっては大幅な改善になりますが、yarnとnpmの両方が同じ戦略を選択するのが最善だと思います（ただし、合意がなく、人々がそれについて強く感じている場合は厳密には必要ありません）。

@ jmorrell-私の理解では、自動変換はここでは悪い考えであることに同意しました。

主な理由は、2つのロックファイル間のデルタがどうあるべきかを知るのが難しいためです。
例えば。 上記の警告を開発者として見たとき、おそらくやりたいことは、他のロックファイルがいつ作成されたか、メインのロックファイルに追加されなかったパッケージが追加されたことを確認してから追加することです。 たぶんimportオプションを参照として使用しますが、必ずしもそうとは限りません。

npm人々がこれに同意することを願っていますか？

理想的には、これが非推奨の状況であり（文言がわからない）、将来のヤーンバージョンでエラーが発生することについての警告を含めたいと思います。 たぶん、これとそれに対処する方法についてのいくつかの詳細なドキュメントにリンクしています。 @ arcanis-それは実現可能だと思いますか、それともwarning振る舞いを続けたいですか？

複数のロックファイルがあるときに両方のツールがerror発行する場合、開発者はまだ「小さい」間にこの問題に追いつき、（参照としてインポートするかどうかにかかわらず）迅速に対処できると思います。 。

@arcanis npm add <pkg>は完全に有効であり、Yarnが行うことを実行します👼

pkglockとyarnlockに関する限り、 package-lock.jsonの当初の意図は、いずれかのパッケージマネージャーが必要とするすべてのデータを含むフォーマットを作成することでした。 実際、 npm@6の時点でのpkglockは、関連するすべてのメタデータを含む完全なツリーを記述しているため、インストーラーを実行せずに透過的にyarn.lockに変換できます。 これを_意図的に_（ requiresフィールドなど）行い、Yarnチームとpnpmチームの両方にフィー​​ドバックを求めて、両方がインポート可能なロックファイルとして使用するのに十分であることを確認しました。代替オプションとして。 残念ながら、yarn.lockは不可逆サブセットであるため、その逆は当てはまりませんが、とにかくインポートするものを追加します。 npmは、Yarnで計算されたツリーの形状にも従います（Yarnとは異なります）。

実際、 npm @ 6以降のpkglockは、関連するすべてのメタデータを含む完全なツリーを記述しているため、インストーラーを実行しなくても透過的にyarn.lockに変換できます。

私はそれができるとは思いません（しかし、私は間違っているかもしれません、誤解を指摘してください）。 Yarnロックファイルは、単一のバージョンに解決される複数の範囲を設計上サポートしていません。 それぞれがlodash@^1.0.0に依存する複数のパッケージがある場合、それらはすべてまったく同じバージョンを使用します。 これは最適化であるだけでなく、ロックファイルで物事をエンコードする方法でもあります。

npmロックファイルはツリーであり、このプロパティは保証されておらず、複数の同一の範囲が異なるバージョンを使用する可能性があります（ノード解決ルールを利用することでわずかに優れた最適化が可能になる可能性があるため、これは問題ありません）。 このような状況では、package-lock.json-> yen.lockの変換は、それらを1つにマージする以外に選択肢がないため、損失が発生します。

一方、Yarnロックファイルは比較的問題なくpackage-lock.jsonに変換できます。これは、ルールがより厳密なサブセットであるためです（マージされた範囲は損失なくツリーに変換でき、ツリーはに変換できません）損失のないマージされた範囲）。 依存関係ツリー自体についてのみ話していることに注意してください。メタデータフィールドについてはよく知りません。

正直なところ、同じことを言っているのか、まったく違うことを言っているのか完全にはわかりませんが、状況を少し明確にしたかっただけです🙂

理想的には、これが非推奨の状況であり（文言がわからない）、将来のヤーンバージョンでエラーが発生することについての警告を含めたいと思います。 たぶん、これとそれに対処する方法についてのいくつかの詳細なドキュメントにリンクしています。

@imsnifこれが非CI環境でのエラーであるとは確信していません（CIについての質問はありません-これは間違いなくエラーを引き起こすはずです）。 単に現在の状態を説明し、それが理想的ではない理由を説明する警告にとどまりたいと思います。

良いことは、 @ jmorrellが警告が十分であったかどうかを確認するための正確なメトリックを提供できることです。それに基づいて、次の動きを選択します。

ここでの望ましい最終ソリューションは、package-lock.jsonが存在する場合に役立つエラー+ヤーンのインポートですか？

はい、「CIでエラーにアップグレード」モードと組み合わせると*それは合理的な最初のステップだと思います！

（*これはまだ存在しません。＃5773Yarn 2.0 WGで言及します）

@ arcanis-ロックファイルについて： @zkatが参照しているのは（ただし、間違っているか誤解している場合は@zkatで訂正してください）、 package-lock.jsonは物理ツリーと論理ツリーを保存し、 yarn.lockは論理ツリーのみを保存します。 したがって、前述のように、 package-lock.json => yarn.lock => package-lock.jsonを変換すると、物理ツリーデータが失われます。 ほとんどの場合、IMOは問題ありませんが、例外があります。 バンドルされた依存関係。

私の個人的な意見では、両方のパッケージマネージャーは、物理ツリーの構築を同期することでメリットを得ることができます。 私が見たものから、物理ツリーの作成方法について明確に定義されたルールをいくつか抽出し、両方ともそれらに従うことができます（理想的にはすべての利害関係者によって維持されるモジュールを使用）。 これにより、互換性の問題が解決されると思います。 yarnは、バンドルされた依存関係に関するいくつかの問題がありますが、各パッケージマネージャーは独自の癖を維持できます。 （確かに、私はこの議論にまったく慣れていないので、私が気付いていないことがあるかもしれません-眠っている犬を起こしてしまったらお詫びします）。

しかし、目前の問題については、
これをCIレベルでキャッチすることは確かに非常に重要ですが、そこにあるエラーは、開発者のローカル環境でのエラーよりも（平均して）デバッグするのが非常に難しいと思います。
開発者が間違ったツールを使用したためにローカル環境でエラーが発生した場合、開発者は（おそらく）一歩も先に進まないでしょう。 彼らはただ「おっと」と言って、他のツールを使うでしょう。 機能を開発してからバックトラックした後、CIでキャッチする代わりに、大幅な時間を節約できます。
警告（ここで前述したように）は、終了ステータスが0の場合、開発者が無視する傾向がある他のかなりの数の警告に飲み込まれる可能性があります。
どう思いますか？

また、上記の状況では、「外部」ロックファイルは当然のことながら.gitignore配置される可能性があるため、CIはそれについて知る機会すらありません。 ぼんやりした開発者として、「まあ、それは私のローカル環境にいくつかのあいまいな警告を与えますが、それはCIを通過します-それはおそらく私の側のローカルな問題です-ああ」

警告（ここで前述したように）は、終了ステータスが0の場合、開発者が無視する傾向がある他のかなりの数の警告に飲み込まれる可能性があります。

私のポイントは、情報に基づいた決定を下すためにデータを収集する方法はあるものの、この肯定はデータに裏付けられていないということです。 この文脈では、人々のワークフローを壊すより根本的なオプションを選択することは、私には少し無駄で潜在的に有害であるように思われます😕

また、「パッケージマネージャーを使っているので、別のパッケージマネージャーを試してみたい」というユーザーストーリーを見落としていると思います。これは、パッケージマネージャーのメンテナーとユーザーの両方にとって非常に重要だと思います。 人々がYarnプロジェクトからnpm6を簡単に試すことができなかった場合（または逆に、npmプロジェクトからYarnを試すことができなかった場合）は素晴らしいことではありません。

私の個人的な意見では、両方のパッケージマネージャーは、物理ツリーの構築を同期することでメリットを得ることができます。

これは別のトピックですが、私は同意しません。 Yarnがnpmであるという誤解があると思いますが、これは正しくありません。 専用のコマンドを使用してプロジェクトを別のプロジェクトにインポートしたい場合は、私がすべてですが、サードパーティ形式からロックファイルをサイレントに変換（または読み取り）することは、災害のレシピです。

• 構成ファイルは無視されます
• 次回パッケージが追加/削除されたときに物理ツリーが壊れます
• パッケージマネージャーに固有の機能は機能しません（ワークスペース、解像度のオーバーライド、リンク：、...）

私のポイントは、情報に基づいた決定を下すためにデータを収集する方法はあるものの、この肯定はデータに裏付けられていないということです。 この文脈では、人々のワークフローを壊すより根本的なオプションを選択することは、私には少し無駄で潜在的に有害な混乱のように思えます

True-データに裏付けられていません。 私は間違いなくここで推測しています（これを強調しなかった場合は申し訳ありません）。 警告修正の傾向を把握することはできるかもしれませんが、これがユーザーにとってどれほど便利であるか、そしてより便利な解決策があるかどうかを把握することはできません。 データに依存している場合、「Herokuのデプロイエラー率にまったく変化がなかった」以外に、包括的なエラーソリューションに向かう結果はないと思います。

私は、人々のワークフローを壊さないことが非常に重要であることに同意します。 そのため、この状況が非推奨であることをユーザーに警告する警告の文言を使用して、 2.0.0重大な変更としてエラーを提案しました。 また、この動作をオーバーライドするために--forceまたはconfigパラメーターの使用を許可できると思います。 （これは、他のパッケージマネージャーの懸念事項を試すことにも対処すると思いますか？）

これは別のトピックですが、私は同意しません。 Yarnがnpmであるという誤解があると思いますが、これは正しくありません。 専用コマンドを使用してプロジェクトを別のプロジェクトにインポートしたい場合は、私はそれですべてですが、サードパーティ形式からのロックファイルのサイレント変換（または読み取り）は災害のレシピです

ここであなたが重要な懸念を提起していると思います。 しかし、あなたが言うように、これは別のトピックであり、私は会話を狂わせたくありません。 たぶん、別の問題でそれについて議論することができますか？

ここでの会話は少し脱線したと思うので、いくつかの説明と要約を付けて整理したいと思います。

1. Yarnとnpmは、解像度と物理ツリーの作成戦略が異なります。これは、両方のプロジェクトが存在するための重要な要素です。
2. yarn.lockファイルとpackage-lock.jsonファイルはどちらも特定の目標を念頭に置いて作成されており、私が見る限り、これらの目標は完全には一致していませんが、いくつかの重複があります。
3. これらの目標の違いは、フォーマットを他の一般的なものより優れたものにするのではなく、異なるものをトレードオフするだけです。

これらに基づいて、両方のフォーマットを維持することは、イノベーションとさまざまなニーズに対応するために実際に重要であると思います。 必要なのは、無料の実験を可能にするために特定のパッケージマネージャー戦略を他のパッケージマネージャーに課すことなく、パッケージマネージャー間のデータ損失を最小限に抑えてプロジェクトの移植性を確保することです。

他のロックファイルに対する確認と警告、および適切な変換と、保存されているものと失われているものについての明確なメッセージが、それぞれの側のユーザーにとって大きな価値として見られます。 したがって、この号のここでの質問は、yarnを実行するときにリポジトリにパッケージロックファイルがあるユーザーにとって最適なフローは

自動変換は潜在的に危険であり、方法なしでインストールに失敗すると、特定の人々を傷つける可能性があるようです。 パッケージロックファイルを持つことがCIモードで意図されていることを知るために、yarnの構成を設定する必要があるのはどうですか？ これは開発者から糸への合図であり、「私は自分が何をしているのか知っているので、矛盾から私を守ろうとしないでください」と言っています。

考え？

パッケージロックファイルを持つことがCIモードで意図されていることを知るために、yarnの構成を設定する必要があるのはどうですか？ これは開発者から糸への合図であり、「私は自分が何をしているのか知っているので、矛盾から私を守ろうとしないでください」と言っています。

@ BYK-いいですね。 1つ追加すると、 @ arcanisがここで不和に私を納得させたので、configフラグが設定されていないときに非ciモードで警告を追加するのも良いかもしれません。 開発者は、プッシュする前にCIビルドが失敗する可能性があることを知る機会があります（また、 package-lock.jsonが.gitignoreれるのを防ぐため）。

@imsnifが述べたように@arcanis ：pkglockには、ツリーの論理レイアウトと物理レイアウトの両方が含まれています。 ツリーの論理バージョン（重複排除した範囲を含む）に従うことで、インストールやインストーラーロジックの実行なしでyarn.lockをメモリ内に構築できます。 ただツリールックアップ:)

NPM 5リリースノートから：

パッケージマネージャー間の互換性を目的とした新しい標準化されたロックファイル機能（package-lock.json）

NPMチームはユニバーサルソリューションとしてpackage-lock.jsonを宣伝しているようです。 その力に加わることは（技術的に）可能ですか？

私が提案したい解決策の1つは、「すでに存在する場合はpackage-lock.jsonのみを使用する」ことです。 これが基本的に、NPMがshrinkwrapからlockjsonファイルに「移行」した方法です。

NPMチームはpackage-lock.jsonをユニバーサルソリューションとして宣伝しているようです。 その力に加わることは（技術的に）可能ですか？

すでに議論しましたが、まだ議論していない場合は、スレッドの残りの部分を確認してください。 これは短期的には起こらないでしょう。

「パッケージマネージャーを使っているので、別のパッケージマネージャーを試してみたい」というユーザーストーリーを見落としていると思いますが、これは関係者全員にとって非常に重要だと思います。

これはおそらく頻繁なことではなく、コンテキストの切り替えです。 少し前にヤーンを選んだのですが、振り返りませんでした。 ロックファイルが存在する理由の深刻さの背後にいくらかの重みを置く方が良いと思います。 無視される警告ではなく、オプトアウトできるエラーにします。 誰かがロックファイルをコミットするとき、それは理由があります。

私たちの統計によると、Yarnユーザーの大多数もnpmを使用しています。 混合_プロジェクト_は一般的ではありませんが、複数のプロジェクトに取り組んでいる1人の人が、npmである場合と、Yarnである場合があります。 問題をさらに複雑にしているのは、npmを直接実行するスクリプトをインストールすることです。

ヤーンを使いたいのですが、私が取り組んでいるプロジェクトのほとんどにはpackage-lock.jsonファイルしかありません。 yarn.lockファイルを追加できません。 yarn importが遅いか、壊れています。 現在私の
_only_オプションは、糸を捨ててnpmに切り替えることです。

糸は、糸のみのプロジェクトのために糸のみの開発者によって作成されていることを理解しています。 しかし、私たちの残りの部分はどうですか？

ねえ@Spongman - yarn importは壊れてはいけません。 これで、 package-lock.jsonをインポートできるようになります。 問題が発生した場合はお知らせください。

＃6103しました

ちょっと@ Spongman-私は問題にコメントしました、この特定のケースは壊れたpackage-lock.jsonが原因

npmはそのpackage-lock.jsonファイルを問題なく使用できます。 糸はより弾力性がある必要があります。

他の問題でこれに答えました-この問題を話題に保つために、議論をそこに移してください。 ありがとう！

私はhttps://github.com/yarnpkg/yarn/issues/3614 （現在254：+1：s）を注意深く見て、参加していました。 その問題は現在クローズされており、議論はここに移されました。

実用的な課題を無視すると、私の意見では、最高のUXは、上部の要約には記載されていないが、 @ thatlittlegitによって言及されているオプションによって提供されます。

最終的な目標は、Yarnとnpmの間で1つのロックファイル形式を共有することだと思います。

これも@BrainBaconのポイントによってバックアップされています：

どのような種類のプロジェクトでも、使用するパッケージ管理ツールを指定する必要があるのは奇妙に思えます。

繰り返しになりますが、実際の課題を1分間無視して、これに対する理論的な反論は、このスレッドの@iarna （および他のスレッドの@jhabidas ）によって行われました。

単一の一般的なソリューションよりもユーザーのユースケースをより適切に満たすことができるため、さまざまなトレードオフを行う複数のアクティブに使用されるツールを使用することには、多くの利点があります。

個人的には、他のスレッド（95：+ 1：s、2：-1：s）の

はい、同意します。Yarnは、可能な限り独立したスペースを維持したいので、より良いエクスペリエンスを提供する柔軟性があります。 そのため、たとえば、YarnのCLIは意図的にNPMと互換性がありません。

ただし、ロックファイルは、Yarnが合理的に独立性を維持できるスペースの外にあると思います。 package-lock.jsonとcomposer.lockは、 package.jsonとcomposer.jsonとともにリポジトリに

..。

Yarnが便利なツールであるためには、開発者がプロ​​ジェクトで標準モデルに従うことができるようにする必要があります。これにより、プロジェクトはツールに依存しなくなります。 結局のところ、Yarnが独自の依存関係ファイルではなくpackage.json上に構築されたのはそのためです。

このスレッドのほとんどを読んだ後でも、最初の評価に同意します-Yarnがリポジトリから同じpackage.json依存関係ファイルを消費し続ける場合、理想的には同じpackage-lock.jsonファイルをリポジトリに出力する必要があります、リポジトリはツールに依存しないままにすることができます。 Yarnがpackage.jsonではなくyarn.jsonから依存関係を読み取った場合、私はこの点を指摘し続けることはありません。

これが理想的な状況であり、シームレスなユーザーエクスペリエンスであることを認めるべきだと思います。 しかし、私は@iarnaの他のポイントを理解しています：

単一のロックファイル形式は、ロックファイル形式間にさまざまなトレードオフがあり、どちらが最適かについてのコンセンサスがないため、起こりそうな結果ではないと思います。

（「両方のツールが互いのロックファイルを相互に理解できることで十分である」ということに同意しませんが）。

リポジトリをツールに依存しないようにするという理想的なシナリオが確実に達成できない場合（そして、さまざまなロックファイルが基本的にさまざまな方法で構築され、さまざまな情報が含まれている方法について多くのコメントがあります）、私たちがどこに向かっているように見えるかはほぼ同じです口当たりが良い、それは：

• NPM / Yarnは、相手のロックファイル（およびこれをエラーにするための構成オプション）を見つけた場合に警告を発します
• どちらのツールも、あるロックファイルを別のロックファイルに変換するためのメカニズムを提供します

いかなる状況においても、相手のロックファイルを変換して削除するべきではないと思います。 これは、開発者がたまたま使用するツールに応じて、新しい開発者が永遠に一方から他方へ、そしてその逆に変換することを意味します（ git commit -aコミットする人が多すぎる場合）。

私も@imsnifのポイントに同意しません：

1つのパッケージにpackage-lock.jsonファイルとyarn.lockファイルの両方が含まれるのには十分な理由はないと思います。

開発者が自分のコンピューターまたは実稼働環境で何を実行するかを指示するのは、思いがけないことだと思います。 必要以上に制限しないことは、少なくとも礼儀正しいことです。 プロジェクトが開発者のチームによってのみ実行され、すべての開発者がまったく同じソフトウェアを実行している場合は、すばらしいことです。 しかし、何らかの理由でYarnよりもNPMの方がはるかに使いやすいと感じる開発者がいるかもしれません。 特にオープンソースソフトウェアを作成する場合は、コミュニティメンバーができるだけ簡単に立ち上げて実行できるようにする必要があります。 NPMとYarnは、 package.jsonから同じ依存関係をインストールするための単なるツールであるため、これらは正常に機能するはずです。 開発者はpackage.jsonを見ることができ、それを解釈するためのツールを持っている必要があり、さらに心配する必要はありません。 これは、このロックファイルの競合が単独で発生する前のケースでした。

ねえ@ nottrobin-私はあなたがどこから来ているのか理解していると思います。 実用的な課題と哲学的な違いを無視すると、さまざまなツールのユーザーがすべて同じロックファイルを消費した方が間違いなく良いでしょう（もちろん、これは私の個人的な意見です）。

しかし、前述の実際的な課題を無視することはできず、哲学的な違いがその場所にあることにほとんど同意しているように見えたので、私たちが得た妥協案（上記で概説したもの）は間違いなく「十分」だと思います。

上記の妥協案に隠された仮定は、ツールの選択は開発者のマシンや本番環境ではなく、プロジェクトごとに行われるということです。

上記の妥協案に隠された仮定は、ツールの選択は開発者のマシンや本番環境ではなく、プロジェクトごとに行われるということです。

はい、これが私にとって最も懸念されることだと思います。上記で概説したシナリオでは、プロジェクトでYarnとNPMの両方をサポートすることは可能だと思います。

最終的に、2つのプロジェクトが、プロジェクトをツールに依存しないようにするという使命を放棄した場合、実際には依存関係ファイルの共有を停止する必要があると思います。 糸は読書に切り替える必要がありますyarn.jsonではなくpackage.json 。 他のものはただ厄介で混乱します。

npmロックファイルにYarnロックファイルがサポートする依存関係のスーパーセットがすでにある場合は、Yarnで両方をサポートしないのはなぜですか？ Yarnはpackage.jsonに切り替えることができ、Yarnが必要とする可能性のある追加フィールドが将来追加される可能性があります（Inkscapeなどの一部のSVGエディターがエディターメタデータを管理する方法と同様）。 その場合、Yarnはnpmと同じ依存関係形式を持ち、yarn.lockとの下位互換性があり、npmロックファイルをYarnがメモリ内で必要とする構造に変換します。

最終的に、2つのプロジェクトが、プロジェクトをツールに依存しないようにするという使命を放棄した場合、実際には依存関係ファイルの共有を停止する必要があると思います。 糸は読書に切り替える必要がありますyarn.jsonではなくpackage.json 。 他のものはただ厄介で混乱します。

おそらく、そうではないかもしれません。 確かに、これにはツール（毛糸）の大規模な破壊変更が必要になります。 より直接的で測定可能な利益を伴う、それほど根本的な変更は受け継がれていません。

私はそれが悪い考えだと言っているのではなく、それが実用的なものだとは思わないと言っているだけです。

私はそれが悪い考えだと言っているのではなく、それが実用的なものだとは思わないと言っているだけです。

私はそれが大きな質問のように思われることに同意します。 しかし、私が言っているのは、これはプロジェクトにとって極めて重要な問題のように思われるということです。

これまで、Yarnは、開発者がNPMの代わりに使用して、 package.jsonプロジェクトのノード依存関係をインストールすることを選択できるツール明示的に選択する必要があります。 これは大きな変更であり、誤って行われるべきではありません。 これは、その呼び出しを行うためのクランチポイントです。

私の考えでは、前進する方法は3つあります。

1. すべてのプロジェクトレベルのインターフェイスでYarnをNPMに合わせる方法を見つけることで、NPMのドロップイン代替品であり続けます（ロックファイルを標準化します）
2. 明示的に異なるプロジェクトレベルのインターフェース（例： yarn.jsonとyarn.lock ）を使用して、意図的にNPMから分岐します。
3. NPMインターフェイスの半分と異なるインターフェイスの半分を提供することを

ここでの3番目のオプションは、ノードスペース全体を混乱させ、両方のツールを大幅に弱体化させると思います。

それでも下位互換性があります。 Yarnにはnpmlockfileコンバーターが組み込まれている可能性があるため、package-lock.jsonを検出すると、Yarnはそこに保持され、メモリ内でyarn.lockの形式に変換されます。 私の知る限り、Yarnのロックファイルはnpmよりも情報が少ないため、npmはこれを実行できません。したがって、私の意見では、Yarnはnpmで標準化するのが最善です。

@nottrobinただし、分析はほぼ正しいと思います。

さて、ご指摘のとおり、プロジェクトではYarnとNPMのどちらかを明示的に選択する必要があります。 これは大きな変更であり、誤って行われるべきではありません。

これは常に当てはまると思います。少なくとも、Yarnが最初にもたらすと宣伝された主な利点である依存関係ツリーの再現性についてです。 yarn.lockをチェックインできますが、他の開発者がそのロックファイルを尊重せずに依存関係を追加/削除した場合、それは実際には役に立ちません。

@ nottrobin- @ Vinnlに同意します。 前述したように、どのように機能するかを誰かに伝える立場にはなりたくありませんが、同じプロジェクトに依存関係をインストールするためにyarnとnpmの両方を使用することはアンチパターンだと思います。

どちらのツールも技術的にはこの作業を行うために多くの作業を行うことができますが、これはメンテナとして私たちが奨励すべきことではないと思います。 交換可能なロックファイルを持つことには他にも無数の利点があります（さまざまなスレッドでのさまざまな議論が示すように）が、個人的にはこれがそれらの1つではないと思います。

しかし、他の開発者がそのロックファイルを尊重せずに依存関係を追加/削除した場合、それは実際には役に立ちません。

はい、私はある程度ヤーンが最初からその泥水にあったと思います- yarn.lockの存在は、それが部分的にそれ自身のインターフェースを持っていたことをすでに意味していました。 それはいつも少し面倒なことだったと思います。それは、人々にNPMからYarnに移動してもらいたいが、戻ってはいけないというYarnの目的を果たしました。

しかし、少なくともNPMがまだ完全にサポートされていることを知っていたので、プロジェクトの意思決定がより快適になったと感じました。そもそもロックが提供されていなかったため、いつものように機能し続けます。

NPMは依存関係をロックするため、これが変更されました。 プロジェクトをYarnにバインドすることを選択した場合、 package-lock.jsonではなく、 yarn.lock最新の状態に保つため、誰かがNPMを効果的に使用できるというのはもはや真実ではありません。事業。

ヤーンはもはやnpmのドロップイン代替品ではないと言っているようですね。 糸のみのプロジェクトでのみ使用されることになっているということですか？

その場合は、yarnのホームページでこの事実を明確にする必要があります。両方ではなく、thisまたはnpmを使用してください。

ヤーンはもはやnpmのドロップイン代替品ではないと言っているようですね。

決してそうではありませんでした。 インターフェースは、ユーザーがそれを使用する方法を理解しやすくするためにnpmをいくらか模倣しましたが、最初からいくつかのことが異なって機能しました。 一部の人々がそれがドロップインの代替品であると考えた主な理由は、npmが比較する機能を欠いていることでした。

npmがいくつかの側面に追いつき、別の方法で実装することを決定したので、異なるアプローチと異なる決定を行うことを示し始めます（たとえば、最近実装されたオフラインミラー機能npmは既存のものと互換性がありません）。 つまり、「安全」ではなく、偶然に機能しただけです。

その場合は、yarnのホームページでこの事実を明確にする必要があります。両方ではなく、thisまたはnpmを使用してください。

実際のところ、移行手順はあります。 あなたの発言は、残念ながら、人々に間違った印象を与える可能性のていることに気づきました🙁私たちは、この段落を私たちの推奨に沿ったものに変更するためのPRを喜んで受け入れます（つまり、チーム間で一貫してYarnを使用するためにプロジェクトで使用される可能性のあるさまざまな機能をすべての人が利用できるようにするため）。

それは決してありませんでした

えーと...あなたはあなたのマーケティング担当者と話す必要があります。 https://yarnpkg.com/lang/en/docs/

Yarnは、パッケージメタデータ形式を含むnpmの多くの機能と直接相互運用し、簡単な移行を可能にします。

マーケティング担当者はいませんが、素敵なPRを受け入れています🙃

この特定のケースでは、それはそれほど間違っているようには聞こえませんが。 私たちは多くの機能と相互運用しますが、すべてではありません。ほとんどの場合、移行は簡単です（最悪の場合、 yarn import離れています）。

移行は無痛です

移行にはあまり興味がありません。 私はここで約束されたものを探しています（これらの人は_間違いなく_マーケティング担当者がいます）： https ：//code.fb.com/web/yarn-a-new-package-manager-for-javascript/

既存のワークフローと同じ機能セットを備えながら、より速く、より安全に、より確実に動作します。

今日の糸はそうではありません。

AFAICTここには4つのクラスのユーザーがいます。

• プロジェクトで糸のみを使用するもの、
• フェイスブックのセールスピッチ（上記）を購入したが、これらのロックの問題のいずれにもまだ当たっていない人、
• 必要に応じてロックファイルを手動で変換するか、他のハックを使用してそれを機能させることにより、非互換性を回避しようと苦労している人は、
• 糸をあきらめてnpmに戻ったもの。

私は本当に最後のカテゴリーになりたくありませんが、それは私がプッシュされているところのようです。

@Spongman何があなたをその最後のものから止めているのですか？ 私たちはおそらくそれを修正することができます;）

@Spongman私は

（おそらくブログ投稿を編集することはできないと思いますが、ここではおそらくWebサイトが最も重要です。）

@imsnifと@arcanisの回答から、ここでの公式の見解は、YarnがNPMとシームレスに連携し続けることを「意図していなかった」ように思われることが

しかし、私は@Spongmanに完全に同意し

いずれの場合も、この問題により、これに対するYarnの立場が以前よりもはるかに明確になります。もちろん、Yarnのメンテナは、選択した方向にそれを選択できます。

しかし、Yarnが（プロジェクトレベルで）NPMとの互換性を維持していると信じていたために、Yarnを使用した人の数を大幅に過小評価していると思います。それ以外の場合は、切り替えを行うことはありませんでした。 https://github.com/yarnpkg/yarn/issues/3614の254：+ 1：sと10： heart：s 、および「 yarn.lockとpackage-lock.jsonをコミットする必要がある」に関する57の賛成

Yarnがその面で責任を放棄した場合、 @ Spongmanと私のチームだけでなく、他の多くのチームも失うことになると思います。

率直に言って、Yarnのみ、またはnpmのみを使用する場合の問題を本当に理解していません。 あなたが言っているのは、基本的に「チームにYarnの使用を強制することはできないので、npmの使用を強制する」ということです。 それは私には意味がありません。 Yarnの機能を使用する場合は、全員にYarnを使用させ、npm機能を使用する場合は、全員にnpmを使用させます。 これと同じくらい簡単です。

中間にあるということは、少なくとも、ビルドがチーム全体で一貫していないことを意味します。これは、前述のように、Yarnの前提に反します。 エンジニアの1人がワークスペースの使用を開始でき、それは機能しますが、npmで機能しなくなります。 オフラインミラーも同じです。 依存関係の解決についても同じです。 さらに悪いことに、一部のフィールドはnpmによって完全に不明であるため、黙って間違ったことをします。

コミュニケーションに関しては、fbのブログ投稿はドロップインの置き換えについて言及していません。 糸が紹介されている部分を引用させてください。 文字通り、ワークフローに取って代わると言っています。 「npmレジストリとの互換性を維持する」ことに混乱したと思います。これは、私たちではなく、npmに持っていくべき公正なポイントです（npm cli、npmレジストリ、そしてもちろんnpm Inc自体があります）。

Yarnは、npmレジストリとの互換性を維持しながら、npmクライアントまたは他のパッケージマネージャーの既存のワークフローを置き換える新しいパッケージマネージャーです。

その最後のものからあなたを止めているのは何ですか？ 私たちはおそらくそれを修正することができます;）

@zkatよろしくお願いします、ありがとうございます。

@ nottrobin-当時私は周りにいなかったので、私は糸の本来の意図について話すことができません。 しかし、私は数十のリポジトリがある混合ヤーン/ npm環境で作業していました。

当時関係したすべての開発者にとって、yarn / npmの選択は、express / hapi、mobx / reduxなどの選択と同じように、リポジトリごとの選択であったことは完全に明らかでした。これは、 npmとしてさらに明確になりました。

開発者が間違ったツールを使用して依存関係をインストールすると、その依存関係が一貫してロックされないため、 npm @ 5の前でも混乱が生じます。 それは私たちのさまざまな環境で問題を引き起こし、これが間違いであることが関係者全員に非常に明白でした*。

これは紛らわしいかもしれません。そして、これがすべての人に100％明確であるとは限らないことは理解していますが、その誤解に合うようにツールを大幅に変更するのは正しいとは思いません。 私の見方では、yarnは、ボックスごとではなく、リポジトリごとにnpmの代わりにドロップされます。

*確かに、混合ヤーン/ npmツールを使用した複数の非ワークスペースリポジトリの特定の状況は、まさにそれらの間違いの可能性に対する技術レベルではなく、人間レベルでは理想的ではなく、最終的に修正されました。 ここではこの例を使用して、正しくアプローチすれば2つのツールが並行して機能することを示します。

率直に言って、Yarnのみ、またはnpmのみを使用する場合の問題を本当に理解していません。

はい、 @ arcanisと@imsnifはあなたが理解していないことを明らかにしました。 私が指摘している唯一のポイントは、多くの人（：+ 1：sを見てください）が同じ「誤」解釈を行い、それを理解しているかどうかに関係なく、YarnがNPMと一緒に機能することを望んでいるということです。 糸が私たちのためのツールではない場合は、そうです。

（最後のポイントは、 @ imsnifで、ノードの依存関係をインストールするためのツールを、expressとhapi、mobxとreduxなどのプロジェクトの選択と比較するのはまったくばかげています。これらはアプリの基本的な特徴です。明らかな違いがわからない場合は、あなたが私の主張を理解していないのも不思議ではありません。）

とにかく、私は今終わりました。 私はできる限り自分の主張をしたと思います。

オープンソースプロジェクトの場合、「チーム」にyarnまたはnpmの使用を強制することは決して問題ではありません。 それは誰にとっても最も便利なものの問題です。 現実の世界ではnpmが王様なので、npmの世界で糸がうまく機能しない限り、それは死んでしまいます。

^これ

それも誤解だと思います。 過去1年間で、Yarnはnpmレジストリへのリクエストの総数の20％から4月には

目前のトピックに戻ることができれば幸いです。つまり、インストール時にpackage-lock.jsonファイルを検出したときに、警告を書き込むためにPRを作成するのは誰ですか。 ありがとう。

Psst、 @ arcanis - https：//github.com/yarnpkg/yarn/pull/5920

素晴らしい：heart_eyes：

これとyarn importでの作業の間に、この問題を解決できますか？

@jmorrellが、これがHerokuの問題にどのように影響するかについての統計を提供するのを待って、これで十分か、何か（警告/エラーなど）を変更したいかを判断できると思いました。

編集：警告はまだリリースされていないので、まだ待つ時間があります。

それも誤解だと思います。

どうして？ npmのトラフィック量は、プロジェクトがオープンソースであるかどうかについては何も教えてくれません。

より正確な評価は、どのgithubプロジェクトに0、1、または2の（yarn.lock、package-lock.json）があるかを数えることです。 個人的には、yarn.lockファイルと_no_ package-lock.json（明らかなものを除く）を持つgithubで（かなりのサイズの）オープンソースプロジェクトを見たことがありません。

別々のロックファイルを保持する場合は、IMOを使用すると、両方のパッケージマネージャーが他方のロックファイルとエラー（おそらくオーバーライドフラグを使用）を検出する必要があります。

すべて-私たちはトピックにとどまり、直接関係のないコメントをオフラインにすることをお願いします（例：Discordチャンネル）。 このスレッドを購読している人はたくさんいますが、公平を期すために、npm <> yarnの議論はここには属していないように感じます。 ありがとう！

トレッド全体を読んだことはありませんが、少なくともあいまいさがあることをIHMOユーザーに通知する必要があります。

npmがyarn.lockファイルを検出した場合、npmは次のように出力する必要があります。
「警告：このプロジェクトはyarnを使用しているようです。おそらく、「npminstall」の代わりに「yarn」を使用する必要があります」

ヤーンがpackage-lock.jsonファイルを参照した場合、ヤーンは次のように出力する必要があります。
「警告：このプロジェクトはnpmを使用しているようです。おそらく、「yarn」の代わりに「npminstall」を使用する必要があります」

そして、上で示唆したように、（package.json内の）パッケージマネージャーを「優先」する方法。

当時関係したすべての開発者にとって、yarn / npmの選択は、express / hapi、mobx / reduxなどの選択と同じように、リポジトリごとの選択であったことは完全に明らかだったと言えます。

これは私にはまったくわかりませんでした。 これまでは、開発者ローカルの選択だと思っていました。複数の開発者は、好きなリポジトリを使用して1つのリポジトリに共存できましたが、一貫して1つだけを使用する方が_もう少し便利です_。 しかし、express / hapiなどの例は良いものであり、それが選択ではないことを明確にしています。 これにより、より多くの可視性が得られるはずです。

package.jsonにフィールドを追加して、プロジェクトで使用するパッケージマネージャーを指定します

"package-manager": "yarn"

すべてのパッケージマネージャーに実装されている場合は、これが最善の解決策だと思います。

パッケージマネージャーは、reduxが必要な場合にエラーが発生するのと同じように、間違ったプロジェクトで呼び出された場合は続行を100％拒否する必要がありますが、そのプロジェクトでmobx関数を呼び出そうとしました。 警告ではなくエラーを発行し、正しいパッケージマネージャーを使用する方法をユーザーに通知する必要があります。

package.jsonにフィールドを追加して、プロジェクトで使用するパッケージマネージャーを指定します
"package-manager": "yarn"

すべてのパッケージマネージャーに実装されている場合は、これが最善の解決策だと思います。

npmにこれを検討してもらいたい場合は、適切な場所でディスカッションを開くことをお勧めしますが、私はこの方向性が気に入らないと言います。 パッケージマネージャー間の収束が発散ではないことを望んでいます。

いくつかの新しい「パッケージマネージャー」フィールドに対して推奨します。代わりに、すでに先行技術を持っている既存のenginesスタンザを推奨します。

ヤーンとnpmのドキュメントはどちらも、使用が予想されるそれぞれのバージョンを指定するために、 engines.npmとengines.yarn使用法について言及しています。 糸のバージョンがengines.yarn満たさない場合、糸はエラーになります。

https://yarnpkg.com/en/docs/package-json#engines-
https://docs.npmjs.com/files/package.json#engines

npmもyarnも「競合する」マネージャーのenginesをチェックしない場合でも（これは素晴らしいことです）、このフィールドを使用することは、どのマネージャーが使用されると予想されるかを他の開発者に伝えるための優れた方法です。 （package-lock.jsonまたはyarn.lockの存在が手がかりとして十分でない場合）

パッケージマネージャー間の収束が発散ではないことを望んでいます。

同意しました。 収束または拒否のいずれか。

しかし、現在のあいまいで誤った中間点は有害です。

他の人のロックファイルの存在下でエラーをスローするだけで、既存のプロジェクトの摩擦が最小限になると私はまだ考えています。

npmにこれを検討してもらいたい場合は、適切な場所でディスカッションを開くことをお勧めします

ありがとう、サインアップしました。 この方向に最近のスレッドがあります： //npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

私の投票は、警告だけでなく終止符をエラーにすることです。そのため、新しいスレッドを開始するスレッドに追加する必要があるかどうかはわかりません。

パッケージマネージャー間の収束が発散ではないことを望んでいます。

こっちも一緒。 それらは現在互換性がありませんが、そのため、相違はすでに発生しており、すでに多くのユーザーやプロジェクトに摩擦を引き起こしています。

チーム間のさらなる話し合いから得られる収束が何であれ、時間がかかるでしょう。 それが到着すると、提案されたエラーを取り除くことができ、ユーザーは簡単にパッケージマネージャーの切り替えと混合を開始できます。

エラーを追加することで、さらなる混乱を回避し、収束の方向への取り組みを停止しません。

いくつかの新しい「パッケージマネージャー」フィールドに対して推奨します。代わりに、すでに先行技術を持っている既存のエンジンスタンザを推奨します。

それは合理的に聞こえます。 私は、互換性のないパッケージマネージャーの存在を検出する特定の方法に執着していません。

説明を追加するために、特に私のユースケースはgatsbyjsです。 状況は、 @ gaearonがここで報告したものとまったく同じ

React Appユーザーを作成するには、プロジェクトがYarnで作成されるため（Yarnがシステムに存在する場合）、これは非常に混乱しますが、npm installを指示するライブラリのドキュメントに従い、ツリー全体が吹き飛ばされます。

この問題を回避するために、gatsbyはyarnを使用しますが、package-lock.jsonも追加します。 しかし、その後、ユーザーは両方のロックファイルを使用することになり、警告が表示されるようになります。 それらの1つを削除するのは簡単ですが、オンボーディングエクスペリエンスが混乱します。

ご意見ありがとうございます。

@ jmorrell - https：//github.com/yarnpkg/yarn/pull/5920は7月25日に1.9.2でリリースされました。1か月ちょっと経ちましたが、それほど時間はかからないことはわかっています（確かにそうではありません）。誰もがアップグレードしました）-しかし、それ以来、Herokuでのダブルロックファイルエラーに関して共有できる洞察がありますか？

@imsnifメールリマインダーをありがとう！ ここでアップデートを見逃してすみません。

これは、2018年に毎週この特定の障害が発生したアプリの数のグラフです。

（私はyスケールを編集しましたが、これは数百人の開発者を表しており、傾向を示しています）

1. 7月の落ち込みは、S3とは無関係の問題によるものです。

2. 7月25日以降の傾向を見ると、この警告はこのエラーを経験している人々の数に大きな影響を与えたようです。 シフトの大きさに少し驚いています。

@ jmorrell-これは本当に素晴らしいです！
私もこれにかなり驚いていることを認めます。

（糸側では）この問題は解決したと考えられます。 同意しますか？

エラーを修正するためにpackage-lock.jsonを削除するというアドバイスは誤解を招くと思います。これにより、一般に異なるパッケージバージョンのセットが使用され、（一般に）非互換性と破損が発生します。 また、このアドバイスは、プロジェクトが使用しているパッケージマネージャーを決定する人にのみ役立ちます。 このアドバイスに従う一般的な貢献者も問題にぶつかるでしょう。

IMOがpackage-lock.jsonが存在し、 yarnがインストールするバージョンが、 npmがインストールするバージョンと同じであることを保証できない場合、エラーで失敗するはずです。

@Spongmanにご入力いただきありがとうございます。 これはすべて、上記の（非常に長い）スレッドで十分に議論されていると思います。また、再起動するのは意味がないと思います。 私たちは皆、あなたの立場を理解していると思います。 参加していただきありがとうございます。

@jmorrellが来週かそこらで別のことを教えてくれない限り、私はこれが完了したと見なし、この問題をクローズします。

@imsnifこれまでの9月（9月1日から9月20日）までの失敗を別の方法で見てみると、これがNodeがHerokuで失敗する最大の理由です。 これは、次に最も一般的な既知の障害ケースの2倍発生します。package.jsonが無効なJSONです。 もう一度正確な数を編集して、これが他の問題とどのように重なるかです。

これについてはnpmからの動きは見たことがないので、そこにも警告を追加してPRを作成し、受け入れられることを確認します。

（糸側では）この問題は解決したと考えられます。 同意しますか？

これはユーザーにとって解決されたとは思いませんし、ユーザーエクスペリエンスはまだ良くありません。 しかし、npmがこのケースをヒットしたユーザーにフィードバックを提供すると、数値がどのように変化するかを確認できます。

これを閉じるか、さらに変更するかは、あなたに任せます。 これがまだユーザーにとって大きな問題である場合は、数か月以内に新しい問題を開くことができてうれしいです。

@ jmorrell-この問題が大きな注目を集めており、会話が再開され、繰り返され続けていることを考えると、私たちが持っている情報で今すぐ閉じる方がよいと思います。

npmが警告を表示しても問題が発生する場合は、間違いなくエラーの議論を再開します（または他の解決策を検討します）。 その場合は、個人的にpingを実行してください。

これを持ち出し、貢献し、これらすべての変更を行ってくれてありがとう！ 個人的には、この号以降は糸の方が良いと感じています。