Yarn: package.jsonに保存せずにパッケージを追加します

いいえ、この機能は意図的に省略されています。 package.jsonに反映されずにパッケージをインストールすることは危険であると考えられています。 なぜそんなものが存在したいのですか？

Facebookの発表から

npminstallの「目に見えない依存関係」の動作を削除しましたコマンドを分割します。 yarn add <name>を実行することは、 npm install --save <name>を実行することと同じです。

私は物事をテストするためにその機能をかなり頻繁に使用していました。 特に、私が維持しているライブラリを使用していて、リリースを作成する前に変更をテストするためだけにローカルバージョン（ file: depを作成する）をインストールする必要がある場合。

デフォルトでそれを行うnpmの実装は悪い選択であったことに同意しますが、これは明示的に使用すると便利なものだと思います。

ええ、明示的なフラグでそれを許可するのは良いことだと思います。現在、これはまだnpm i =）を使用できますが、npmの必要性を取り除くためだけです。

それはに不可欠の変化だと私たちは、これを明示的にサポートしていませんnode_module 、その後で拭くことになるyarn install我々は考えるので、S package.jsonとyarn.lockなければ真実の源。

Windows（libxslt）に簡単にインストールできない依存関係があるため、次のようになります。

• Windowsの場合：開発者はnode_moduesで解凍します
• Linuxの場合：開発者は保存せずにインストールします（package.jsonにある場合、ビルドが失敗するため、Windowsを使用している開発者はインストールを実行できません）

糸を使用してそれを行うためのクリーンな方法（またはこの結果を達成するためのより良い方法）はありますか？

（パッケージはpackage.jsonに反映されるべきであることに同意しますが、ここではクリーンなソリューションを見つけることができません）

@GuillaumeLeclerc yarn add -D xxxどうですか？package.jsonからエントリを自分で削除しますか？

次回別のパッケージが追加されたときに削除されますか？ そうじゃない？

@GuillaumeLeclerc残念ながら、はい。

@GuillaumeLeclercコメントをクリーンアップすることをお勧めします...

package.jsonまたはyarn.lockを変更せずにモジュールをインストールできるように、 yarn add --no-saveような引数を追加してください。 モジュールにコミットする前に、モジュールをテストする必要があることがよくあります。

「最大呼び出しスタックサイズを超えました」というメッセージが表示されるため、通常のnpm install使用できません。 したがって、糸はインストールする唯一の実行可能な方法です。

package.jsonyarn.lockへの変更を元に戻さないでください！

私にとって、peerDepをインストールしようとしているので、これは私を噛みます。 Yarnにはinstall間にピアデップをインストールする方法がないため、手動でインストールする必要があります。 package.json / yarn.lockに追加しないとyarn add <package>できません。 私は立ち往生しています。

@viveleroiこれは完全に正しいように聞こえます。 package.json追加せずに、ピアの依存関係をインストールするのはなぜですか？

@hpurmann peerDependenciesをdependencies （またはdevDependenciesを使用する場合は--dev ）に複製しているためです。 それが意図されているのであれば、それは確かに直感的ではありません。

@hpurmann反応コンポーネントを公開したいので、reactはpeerDepである必要があります。 ただし、プロジェクトを開発するには、プロジェクトにreactをインストールする必要があります。

--no-saveを追加するだけです=>それはとても重要です
特定のパッケージの特定のオプションの依存関係をスキップする必要があります。 私はあなたの糸でそれをすることはできません。 --no-saveオプションを使用している可能性があります。

yarn link local-pkgはlocal-pkgの依存関係をホストアプリにインストールしないため、直接インストールしたいのですが、公開されるとlocal-pkgによって提供されるため、アプリpackage.jsonに保存しません。 。

なぜオーナーがこんなに意見を言っているのかわかりません。 あなたがそれの使用法を見ないならば、それがないという意味ではありません。 人々がそれを求めれば、それは彼らがそれを必要としていることを意味し、彼らは必ずしも愚かではないと私は信じています。
オプションの--no-saveオプションを追加すると、一部の人々の問題が解決され、欠点はまったくありません。

AWSLambdaで実行されるNodeJSプロジェクトにYarnを使用しようとしています。 この機能がサポートされていない理由にはちょっと驚いています。 私のユースケースは、ローカル開発環境にaws-sdkをインストールする必要があるというものですが、AWS Lambdaがすでに環境にインストールしているため、 package.json保存したくありません。 aws-sdkを含めることは、最終的なパッケージが肥大化することを意味します。

ヤーンリンクとヤーンアドは共存できません。 ヤーンの追加はpackage.jsonに依存しますが、ヤーンリンクはローカルパッケージを別の場所にリンクするだけです。

Yに依存するパッケージXを開発しているとすると、あなたはXとYの両方の開発者であるため、XとYをローカルに保持し、YをXのディレクトリにリンクします。Xにyarn addを実行すると、ワイプアウトされます。 Yへのリンク。

これをどのように回避しますか？

〜そのような場合は、パッケージjsonまたはyarn.lockにフットプリントを作成せずに、npm-commandsを使用してインストールできます：〜

〜 npm install [packages ...] --no-save --no-package-lock 〜

@heikomatが以下に述べるように、npm5はインストール後に自動プルーニングを使用するため（https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921を参照）、これはオプションではなく、node_modules-folderを完全に壊す可能性があります。

さて、今はnpmなしでは生きられません

ローカルサブモジュールの依存関係をメインnode_modulesにインストールするスクリプトの1つでnpm installを使用していました。 これはnpm4で正常に機能していますが、npm5はインストール中に一部のパッケージを削除することを決定するため、npm5では完全に機能しません-.-（https://github.com/npm/npm/pull/18921を参照）

そのため、スクリプトのnpm installをyarnに置き換えようとしましたが、インストール中にyarnが常にローカルサブモジュールのpackage.jsonsに接触する場合は、実際にはそれを行うことができません。私のスクリプトは静かに乱雑になり、糸の後で「クリーンアップ」します

すでに--no-lockfileオプションがあるので、node_modulesフォルダーが考えられなくなります。
ただし、開発者はpackage.jsonを不変に保つための回避策が必要です。

ありがとうございました。

私は、誰かがモジュールをインストールするための彼らの独特のユースケースを説明するが、それを記録しないたびに、メンテナが戻ってきて彼らのシボレスを暗唱する方法が好きです。 道徳的な失敗に苦しんでいる人々から来ているのと同じように多くの異なる人々からの同じ要求を受け入れることができれば、あなたの頑固さに自信を持って簡単に感じることができなければなりません。 妥協案として、スイッチに--i-am-a-heritic-and-a-bad-programmerという名前を付けることができますか？

yarnがnpmから保持している1つの重要な欠陥を見るのは悲しいことですが、それは組織外の誰にとっても敵対的です。

そして私の場合、＃4297問題の回避策としてそれを使用したかった:)
開発者が物事を行うことを人為的に制限すると、特定の状況で製品が使用できなくなる可能性があります。

冗談でしょ？ これは悲劇です。 すべての開発者ワークフローがどのように機能するかを指示するのはやめてください。 これがまさにNPMが私たちに合わなかった理由であり、私たちはYarnに移動しました。 「package.jsonとyarn.lockは信頼できる情報源でなければならない」というこのイデオロギーは無意味です。 パッケージは、ソースコードを変更せずにインストール可能である必要があります。 そのような単純な。

さあ、メンテナ。 コミュニティがこれを本当に必要としていることは明らかです。 フィルタリングされていない、見当違いの哲学でインテリジェントな会話をシャットダウンするのをやめてください。

requireをテストする必要のあるモジュールがあり、テストするにはサンプルモジュールを./node_modulesにコミットする必要があるため、 yarnがテストに失敗することがわかりました。 yarn installを実行すると、Yarnがサンプルモジュールを削除しています。 もっと「真実の源」の衒学者だと思います。

ユースケース：私が使用するツール

これは、Angularスタイルガイドにcodelyzerを使用することで非常に苛立たしいことですが、チームの他のメンバーは使用せず、コードの機能に影響を与えません。 今それを機能させる唯一の方法は、それを私のヤーンロックに追加し、私のヤーンロックが実際に変更されていないと仮定するか、私のチームがヤーンを使用していてもnpmを使用することです。 これらは両方とも恐ろしいオプションです。

すでに2018年ですが、有効なユースケースが多数あるにもかかわらず、この機能はまだ追加されていません。

これが役立つ理由をもう1つ挙げると、次のようになります。

新しいバージョンをインストールしてテストを実行し、それをpackage.json / *.lock保存してその変更をコミットするか、エラーが発生した場合はロールバックすることで、依存関係を自動的に更新するスクリプトがあります。 古いバージョンを記憶して明示的にaddingを再度実行する代わりに、 yarn再度実行する方がはるかに簡単です。

さらに、テストを中断せずにこの依存関係を実際に更新できることを「絶対に」確認する前に、信頼できる唯一の情報源（ package.json ）を変更しない方がクリーンです。 今のところ、コードを壊す依存関係を含むpackage.json （一時的であっても）になります。

この問題には多くの有効なユースケースがあります。 作成された場合、yarnpkgのメンテナはPRを喜んで受け入れますか？

まだこのプロジェクトに参加している場合は、 送信してください...

それまでの間、 package.jsonのscriptsセクションで次のスクリプトを使用します。

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

毛糸の代替品があると思いますか？

代替手段はありません。npm5は私の人生として厄介です。

また、シンボリックリンクを.binフォルダーにコピーすることを忘れないでください。 ;）

私にとって、 chmod 444 package.jsonとyarn add XXXX --no-lockfile 、少なくともローカル開発とテストの問題を回避します。
追加は（予期される）アクセス許可エラーで終了しますが、追加されたモジュールは後でnode_modulesに存在し、ローカルにインストールされているがpackage.jsonに永続化されていないピア依存関係で、ピア依存関係としてテストできます。

why-is-node-runningように、一時的にデバッグライブラリが必要になることがあります。 一度使用した後でそれを取り除きたいと思うことはわかっています。 --no-saveオプションを使用すると、依存関係を汚染するリスクを冒すことなく、インストールして忘れることができます。

私はLernaを使用していますが、プロジェクトは前のステップで既にビルドされており、アーティファクトが引き継がれているため、公開段階でCIステップの1つに_only_Lernaをインストールしたいだけです。 それは有効なシナリオですか？

この機能が利用可能であれば、いくつかの手順を節約できます。
私のnode_modulesはとにかく.gitignoreにあります。

の代わりに：

git clone external-package (needed for temp testing only)
yarn install
yarn link

元のリポジトリに戻る
yarn link external-package

ただ：
オリジナルリポジトリ：
yarn install external-package --no-save

ビルドパイプラインの一部として、nspをインストールして実行し、dependency-check.xmlをエクスポートする必要があります。

この単純なツールのインストールをパッケージリストに反映する必要がある理由がわかりません。タグをプッシュする前に、変更を元に戻すためにgit checkout ${BRANCH_NAME}を実行する必要があることを意味します。

ソースを変更しようとはしていません。 私はしたくありません、そしてそれは私のビジネスではありません、それは私の組織の開発チーム次第です。 あなたは私の人生を抽象的な哲学のために少し難しくしています。 やめて。

何か考えがありますが、なぜこの問題は解決されたのですか？ --no-saveスイッチがPRに追加されましたか？

依存関係から持ち込まれたモジュールのバージョンを変更したい場合があります。 たとえば、別のdev依存関係によって持ち込まれた@types/sinonは、最近私のtscを壊しました。 開発者の依存関係に@types/sinonを追加したくないのですが、作業を続けることができるように、 yarn add @types/[email protected] --no-saveバージョンを手動で変更したいと思います。 代わりに、npmに切り替えます。 超イライラする。

プラットフォーム固有のバイナリのハック自体である本番環境のみの依存関係（appdynamics）があります。 開発マシンでは必要ないことがわかりました。 yarn add ... --no-saveを追加すると、スクリプトがpackage.jsonを危険にさらすことなくクリーンにデプロイできます（特にpackage.jsonは、各スクリプトまたは依存関係の目的を説明するコメントを付けることができないため）

cc @kittens @hpurmann

この非常に人気のある問題に対処するか、解決済みとしてロックしてください。 上記のすべての批判に応えて具体的な回答をいただければ幸いです。

そして、コミュニティはこの機能を提供する準備ができています。そのようなプルリクエストを受け入れるかどうかをお知らせください。 ありがとうございました。

ハハ、まだ実装されていない、niiiiice

なぜそんなものが存在したいのですか？

JSXが最初にテンプレートとロジックの混合を発表したときに人々が言っ​​たのとまったく同じことでした。 それが可能であり、そのユースケースがある場合、正しい質問はなぜそうではないのでしょうか？ つまり、これはフラグであり、デフォルトの動作ではないため、yarnに明示的に伝えています（別名、私が何をしているのかを知っています）。

@kittens @hpurmann
私はreactに基づいて複数のパッケージを持っており、これらにはサブモジュールの依存関係があります。 だから私はpeer-depとしてreactとreact-domを持っていますが、これらのパッケージを個別にビルドする必要があるときは、reactとreact-domが必要です。
これは、パッケージをdepとして追加せずにローカルにインストールするための適切なユースケースになると思います。
私のプロジェクトでこのような些細な使用のためにnpmを使用したくありません。
--no-save似たものを待っている更新。
開発者がその副作用を認識していると仮定すると、コミュニティが要求する場合、機能を追加しても害はないと思います（yarnインストールを実行するとすぐにローカルパッケージが失われます）。
ありがとう

便利なトリックはyarn add --dev pkg && yarn remove pkgです。 それは同じことをします。 ロックファイルはそれ以前の状態のままなので、そのままです。

これは@Legendsによって以前に言及され

場合によっては、必要なパッケージを別のフォルダーにインストールし、必要なパッケージを追加された場所にyarn linkインストールすることを回避できます。 それは理想的ではありませんが、助けることができます。

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorbは絶対に価値がない、私見。 add + removeは、npmの--no-saveで行われることとまったく同じです。 システムリンクを混乱させたり、ロックファイルに悪い方法で触れたりすることはありません。つまり、 yarn remove後も同じです。
言うまでもなく、プログラムでそのことを実行したい場合は、間違いなくdirを作成したり、リンクしたりすることはできません。

ある場合

例えば？ 確かにかなり奇妙なもの？

@hpurmann @kittens

では、ピアの依存関係を持つパッケージを開発するための推奨される方法は何ですか？

たとえば、パッケージにReactをpeerDependencyとして持っている場合、インポートを解決するために、それをdevDependencyとしても追加する必要がありますか？

https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.jsonを見ると、答えはイエスだと思います

@ 18stepsはhttps://www.npmjs.com/install-peersをチェックアウトし

この機能を使用する状況がいくつかあります。

CIライフサイクルと同じように、カバレッジレポーターを追加しました。 しかし、それらをpackage.jsonに移動することはできず、 NPM公開に影響します。

保存するかしないか、この選択はツールではなく開発者自身に任されるべきだと思います。

さて、これをメンテナの視点から見てみましょう。 素朴な--no-saveソリューションの欠点は間違いなくわかります。 ここではあまり詳しく説明していませんが、鋼の男を作ってみます。 多分彼らは私を正すことができます。 妥協点を見つけることができるかもしれません。 @kittens @hpurmann

（申し訳ありませんが、これは私が意図したよりも長くなりました。）

最新のノードおよびWebアプリケーションの依存関係管理は少し混乱しています。 それでも、重複排除や再現可能なビルドなどの機能を備えた、信頼性の高い自動化と一定レベルの制御と予測可能性の両方を提供するシステムが必要です。

複雑さを把握するには、何がインストールされているのか、その理由を知る必要があります。また、矛盾を解決するための信頼できる唯一の情報源が必要です。 明らかなことを述べるリスクを冒して、 node_modules自体はこれらの役割のいずれも果たすことができません。 トラバースするには遅すぎ、送信するには大きすぎ、バージョン管理にはきめが細かく、「理由」の側面をエンコードできません。 そのため、 package.jsonとyarn.lockます。

Yarnは、インターフェースを介したアクセスを制限することにより、 node_modulesの複雑さをカプセル化します。 カプセル化を破らないことを約束した場合、重複排除や再現可能なビルドなど、一定の保証が得られます。 package.jsonとyarn.lockに対応する変更を加えずに、 node_modulesにインストールすると、それらの保証は失われます。

さらに、それは多くの開発者が明確に認識していない暗黙の契約です。 彼らがそれを壊すとき、彼らは故意にそうしません。 したがって、問題が発生した場合、Yarnは不当に非難される可能性があります。 さらに、足で自分を撃つのが難しいツールを作ることは悪い設計哲学ではありません。

ただし、妥協する理由はいくつかあります。

• ここには明確な必要性があるようです。 上記のコメントにリストされている多くのユースケースと、「賛成」/「反対」の比率を見てください。 そのような一方的な反応に直面したメンテナの明らかな頑固さは、ヤーンの見栄えを良くしません。

• すべての人に役立つ可能性のある解決策が見つかります。 たとえば、新しいファイルyarn.local.lock導入します。 開発者はそれを.gitignoreに入れ、 --no-saveフラグとその依存関係とともにインストールされたすべてのパッケージの記録を保持します。

  yarn.lockこれから分離しておくために、「ローカル」依存関係ツリーの重複排除とフラット化が制限されています。 ローカルロックファイルは、メインロックファイルのバージョンと一致するように適応する場合があります（その場合は重複排除）が、その逆はできません。 その結果、多くの推移的なローカル依存関係がnode_modules平坦化されない可能性があります。

  このソリューションにより、Yarnは引き続きすべてのパッケージを追跡でき、開発者はリポジトリを汚染することなくインストールでき、再現可能なビルドを保持します。 （ devDependenciesセクションのあるpackage.local.json余地もありますが、それが必要になるかどうかはわかりません。）

• とにかく欲しいものを手に入れるために、人々はすでに回避策を使用しています。そのうちの少なくとも3つは上記のコメントで説明されています。 しかし、それらは使用するのに不便であり、同じ保証を提供せず、開発者がそれらを理解するためにYarnと戦うことを要求します。 それは両方の世界の中で最悪です。

私は何かを逃したかもしれませんが、これは持つ価値のある会話のようです。

別のユースケースがあります。モジュールをREPLで使用できるようにしたいのですが、コードで使用するつもりはありません。 現状では、別のフォルダーに移動してそのモジュールをインストールし、 ../other-project/data/xyz.jsonを使用していくつかのjsonファイルをインポートする必要があります。

しかし、モジュールをインポートしたいのに、相対パスを使用して他のモジュールをインポートする場合は、問題が発生します。

保存せずにモジュールをnode_modulesインストールさせるだけで、すべてがはるかに簡単になります。

メンテナがこの考えにどれほど抵抗力があるかに驚いています。

よろしくお願いします。前のコメントを読んだだけで、メンテナの態度はがっかりしています。 フレームワークライブラリに依存する多くのフレームワーク固有のプラグインを開発していますが、それらをハード依存関係としてプラグインに追加することは避けたいと思います。

peerDependenciesで定義された特定のパッケージに依存するプラグインがありますが、他の多くの人がすでにコメントしているような問題は、依存関係をpackage.json追加せずにローカルにインストールする方法です。ファイル？ まあ、できません。

私が見つけた唯一の解決策は、 peerDepenciesをdevDependenciesとしてインストールすることです。これはまったく理想的ではありませんが、問題を回避できます。 恐ろしい状態の少なくともnpmは、 package.jsonファイルを変更せずにインストールされます。

@hpurmann @kittens

コミュニティへの対応をあきらめましたか？ 明らかに、この問題を無視しても何の恩恵も受けず、なくなることもありません。 誰かが仕事をしてPRを提出するかどうかという単純な質問に答えるつもりさえないのであれば、これをオープンソースプロジェクトと呼ぶ意味は何ですか？それを受け入れますか？

@viveleroiが彼の非常に有効なユースケース（多くの人が持っているようです）を説明した直後に、私はおそらく少し前に答えるべきでした。 当時、私は彼の反応を高く評価しましたが、それは明らかに注目を集めるのに十分ではありません。

私は自分の考えを変えました。 通常、人々は多くのことを望んでおり、メンテナがすべての機能を受け入れている場合、ソフトウェアは肥大化します。 私はこのユースケースを持っていませんが、多くの人がそれを望んでいるのを目にします。

でも何も決められません。 私はこのプロジェクトのメンテナではありません。

@Vheissu yarn add --peer <dep>の問題は何ですか？

私にとってはyarnadd --peer別のパッケージを追加するまで機能します。追加すると、既存のピアdepsがローカルインストールから削除され、手動で読み取る必要があります。

今日はexpressを使用してライブラリの実装例を書いているので、この機能が必要ですが、私のコードはどれもexpressに直接依存していません。 Expressをインストールしたり、Expressに依存したりしたくないのですが、現在のディレクトリにインストールしたいと思います。

ただ、ブレンダン・ハーリー@suyanhanx @のように、私はCIではなく、ローカルにインストールすることを依存関係を持っています。
node_modulesを膨らませたり、プロジェクトに取り組むすべての開発者に時間とスペースを費やしたりする必要がないように、ローカルの依存関係を最小限に抑えたいと思います。

CIで必要であるが、ローカルでは必要とされないパッケージ：

• CI固有のツール：セマンティックリリース、greenkeeper-lockfile
• カバレッジレポートツール：codacy-coverage、coveralls
• CIのテストレポートツール：jest-junitなど。

この機能が必要な理由は次のとおりです。

yarn linkを使用しても、パッケージの依存関係はリンクされないため、にインストールする必要があります。
リンクされた宛先-これらの外部依存関係をpackage.json追加すると、非常に不便になります。

yarn linkは依存関係を追加するか、宛先package.jsonを除外する方法を提供する必要があります

私にはかなり難解なユースケースがありますが、これは私にとって役に立ちます。 yarn.lockとpackage.jsonが真実の源であることが重要である理由を完全に理解しています。また、 --no-saveコマンドを使用すると、後続のyarn変更が消去されることを理解しています。

そうは言っても、 yarnが私を信頼して、私が何をしているのかを知ってもらい、 --no-saveフラグを渡すことができるようになることを願っています。 問題のいずれかに遭遇した場合、何が悪かったのかを正確に知ることができ、自分のせいにするだけです。 ：スマイル：

私のユースケース？
私は64ビットのwinマシンを実行しています。
製品マシンは32ビットです。

パッケージを更新しない限り、ノードとSassの依存関係は32ビットのみをサポートします。

開発マシンをサポートするためにpackage.jsonまたはyarn.lockの依存関係を変更しません。
したがって、64ビットをサポートするために最新のnode-sassをローカルにインストールしたいのですが、package.jsonとyarn.lockには影響しません。

VSCodeでのオートコンプリートを改善するために、 package.json / yarn.lockを汚染せずに、TypeScript以外のプロジェクトに@types/*パッケージをインストールしたいと思います。

私は糸のワークスペースでlernaを使用しています。
@ types / react @
Antdは週末にこれを修正します。
しかし、現在のpackage.jsonに影響を与えることなく、手動で@ types / [email protected]の修正バージョンをworkspaceRootにインストールするようにyarnを強制する必要があります（最新バージョンが自動的にインストールされるため）。

package.jsonに保存するというデフォルトの動作を維持することは正しいですが、開発者がpackage.jsonに影響を与えずにモジュールをインストールする必要がある場合が実際にあります。 特に、一部のパッケージに予期しない重大な変更があった場合。

パッケージを暗黙的に更新し、package.jsonに暗黙的に保存すると、競合が発生します。

別のユースケースがあります。 私はReactライブラリを維持しています。 新しいバージョンを公開する前に、 reactとreact-domいくつかのバージョンに対してテストを実行して、変更が後方および前方（ @next ）と互換性があることを確認したいと思います。 以下の設定を使用してこれを行っていましたが、Yarnのワークスペースを使用したいので、Yarnに移行する必要があります。

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

このスクリプトでpackage.jsonを変更することはできません。変更すると、ステージングされていない変更が原因で公開コマンド（ pack publish ）が失敗するためです。

package.jsonファイル（読み取り専用ファイルマウントの可能性があります）に触れずに、テスト目的でCIパイプラインにパッケージを追加したいと思います。
これらは開発コンポーネントの一部ではありません。
開発マシンでの開発およびテスト中はインストールせず、ビルドおよび製品化中はインストールしないでください。テスト中にCIサーバーでのみ必要かつ受け入れられます。

これはnpmを使用するだけで機能しますが、yarnはnpmの依存関係を取り除くことができるはずです。
これにより、yarnのみではなくnpmのみを使用できるようになる可能性があります。

また、npmができることを実行できないため、npmを完全に置き換えることができるという約束を破るだけです。

また、これは通常のユースケースではなく、エッジのユースケースである必要があるため、この機能をフラグの背後に完全に隠します。

冗談ですか ？ 簡単なスイッチを追加するのに3年？

別のユースケース：コミット前のチェックにnpmパッケージ（ git-hoooks ）を使用します。 チームの全員がノードをインストールしているわけではないので、それをpackage.jsonに含めると、一部の人のコミットが壊れてしまいます。 だから私はgit-hooksをインストール/削除することでフックを一時的に有効/無効にするnpmスクリプトを作成しようとしています。 この一見単純で簡単な作業を糸で達成することは事実上不可能であることに気づいたことに非常に失望しました。

心配なのは、yarn.lockがnode_modulesの内容の真実のソースではなくなるということですが、それについて何が悪いのでしょうか。 既存の関数は、追跡されていない依存関係の存在を単に無視することはできませんか？ 糸は素晴らしいツールであり、メンテナはJSコミュニティに素晴らしいサービスを提供してきましたが、この決定を再考する必要があります。

冗談ですか ？ 簡単なスイッチを追加するのに3年？

@spanasikと@Ryuurock ：無料で提供されている高品質のソフトウェアについて話し合うときは礼儀正しくしてください。

スイッチが複雑すぎて実装できないため、これは「3年」かかりませんでした。これは、メンテナがユーザーにとって正味のメリットになると確信していないためです。 これに同意できない場合は、その機能について議論してください。

@NickHeinerは、10画面の引数です。 そして、欲求不満を引き起こす主なことは、メンテナが納得していないということではなく、それを無視しているということです。人々が「これに同意しない場合は、機能について議論する」場合は、議論に答えないでください。 そして、人々が欲求不満を感じるとき、もちろん彼らは不快なコメントを残します。 すべてをユーザーのせいにしないでください。

私は、メンテナがここでの議論に取り組むほうがよいことに同意します。 数年にわたって幅広い人々から明らかに関心が寄せられています。 したがって、 @ spanasikと@Ryuurockが単に「議論をする」べきであるという私の提案は、ここの他のすべてのように無視される可能性が高いため、不合理です。

そして、人々が欲求不満を感じるとき、もちろん彼らは不快なコメントを残します。 すべてをユーザーのせいにしないでください。

同意しません。 この無礼さはまだ有用な前進ではなく、大人の間で受け入れられる行動でもありません。 失礼であることは、メンテナがこれをさらに無視することを正当化するための優れた方法です。「スレッドはただのトロールです」。

前進するための建設的な方法：

1. 他のチャネルのこのスレッドにメンテナの注意を引き（おそらく無視しているかもしれません）、同意しなくても、少なくともここでの議論を認めるように依頼します。
2. 糸をフォーク/交換し、人々がより幸せな方法でプロジェクトを管理します。

便利なトリックはyarn add --dev pkg && yarn remove pkgです。 それは同じことをします。 ロックファイルはそれ以前の状態のままなので、そのままです。

テスト済み-動作しません。

私のユースケースは次のとおりです。
一部のパッケージには、「require」でロードされるオプションのアドインがあります。 これらのアドインをdevDependenciesセクションに追加したくないので、「yarn add my-add-in」を実行して、package.jsonファイルから手動で削除します。 私のクラウドCIパイプラインでは、「npm i」を使用してそれらを追加します（テスト用）。 ローカルパイプラインでは、余分なロックファイルが作成されるため、npmを使用したくありません。 私の最善の選択肢は、npmを使用してから、ロックファイルを削除することです（表示されている2番目のバージョンの真実を削除するため）。

したがって、すべてを読んだ後、メンテナへの私の質問は次のとおりです。

• なぜそんなに一貫性がないのですか？
• この哲学をすべての機能に実装してみませんか？
  
  
  
  • つまり、私たち全員のために物事をどのように行うべきかを決定し、すべての機能から他のすべてのオプションを削除します。 コースにとどまります！ 自分に素直にいて！
  
  

否定できない事実は、優れたソフトウェアはユーザーが自分の状況に最適なものを選択できるようにするため、すべての優れたソフトウェアには構成設定があるということです。 そして、常に「package.json」ファイルに触れることは良い習慣ですが、この哲学のために「yarn」がタスクに対応できないというエッジケースが存在します。

シンプルで速いので、私は本当に糸が好きです。 メンテナが確実に負ける戦いを戦っているのは本当に残念です-コミュニティは物事を機能させるために遅い信頼できるnpmに戻ることを余儀なくされているからです。

少し温度を下げましょう。 誰もが嫌悪感を感じる必要はありません
彼らが無料で使用することを許可されているソフトウェアの一部。

2020年1月15日水曜日23:17山崎肇Vukelic <
[email protected]>は書いた：

糸が私をある意味で働かせてくれることにうんざりしています。 私はするのが好きです
自分で物事を決めるのですが、ツールが私にどのように教えてくれるのかが気に入らない
うまくいくはずで、私の知性が問題の中で最も少ないことを侮辱し、そして
物事を成し遂げることができないことは、群を抜いて最大です。

完璧なルールを信じ、その機会は決してないだろうと信じること
それらを壊すのはナイーブです。 「ベストプラクティス」と「ベストプラクティス」には違いがあります
「ドゥーオアダイ」。 オリバーウェンデルホームズシニアが言うように：

若い男は規則を知っていますが、老人は例外を知っています。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
。

あなた自身のパッケージマネージャーを作ってください、誰もあなたに何もさせません。

まったく怒っていません。ロジックのエラーを指摘するだけです。

糸は私を特定の方法で働かせます。

糸はあなたに何もさせません、彼らは（無料で）ツールを作りました、そしてそれは特定の方法で働きます。 気に入らない場合は、他のものを使用してください。

@foxbunny嫌悪感を明確にしていただきありがとうございます。 :)

この場合、それが合理的で嫌悪感を覚えると信じていても、この無料で利用できるツールを作成した人々と話すための丁寧な方法は言語ではないと思います。 敬意を払いながら建設的なフィードバックを送ることができます。

@whitecolorチームはポイントを獲得しました。 そのオプション--saveはばかげています。 ヤーンは、node_modules、package.json、およびロックファイル間の平衡を保証します。これはすばらしいことです。 それはより安全です.... npm--saveは危険です。 何度もがっかりしました

止めて下さい

または、誰もが自分の考えどおりに機能するツールを使用して、落ち着いてはどうでしょうか。

私のユースケースは

アプリのサブ依存関係を更新したい
この依存関係をyarn linkにリンクします
次に、アプリでリンクされたものを使用します
ライブラリに依存関係を追加します
追加されたlib依存関係は、 yarn install （wtf no.1）の後にメインアプリにインストールされません
次に、アプリに保存せずにすばやく追加して、ライブラリに更新を公開する前に機能するかどうかを確認できるようにします。
しかし-いいえ。

ありがとう

コミュニティが作者に無視されているのを見て申し訳ありません。

オープンソースのボランティアとして、首尾一貫した哲学または
プロジェクトは大きな泥だんごに劣化します。 これは時々言うことを意味します
人々は「ノー」です。 同意できない場合は、独自のパッケージを作成してください。
マネージャー、ちょうど糸がnpmを置き換えたように。

3時53分アルトゥールKwiatkowskiで火、2020年3月3日には[email protected]
書きました：

コミュニティが作者に無視されているのを見て申し訳ありません。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/yarnpkg/yarn/issues/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
。

私はLernaを使用していますが、プロジェクトは前のステップで既にビルドされており、アーティファクトが引き継がれているため、公開段階でCIステップの1つに_only_Lernaをインストールしたいだけです。 それは有効なシナリオですか？

^私の元のコメント-正直なところ、なぜこれが必要になるのかわかりません。また、このスレッドがそれほどひどく爆発することも知りませんでした-しかし、それについての電子メールを何年も見るのは面白いです。

私はここでメンテナに同意する傾向があります：

1. 私は自分の主張に納得していません。 メンテナはバカな議論だと言わず丁寧だったと思います。
2. 誰かがPRを上げたとしても、機能の継続的なメンテナンスはメンテナにさらなる負担をかけ、コア製品のメンテナンスを妨げることを意味します。
3. この種の機能は、初心者や比較的熟練していない糸の消費者を想定しないことによって誤用され、ポイント2をさらに永続させます。

いずれにせよ、この機能の必要性を軽減するための、より優れた、よりアーキテクチャ的に適切な方法がおそらくあります。

この機能を実現するためにyarn-add-no-saveを作成しました。 プロジェクトのローカルまたはグローバルにインストールできます。

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

インストールしたら、次のコマンドを実行できます。

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

私のユースケースは、 peerDependenciesを宣言するモジュールをテストして、ツールにそれらを自動的にインストールするいくつかのオプションがあり、すべてのオプションが実行されることを確認することです。

$yarn add-no-save --help

注：パッケージを保存せずにインストールするためにパッケージを保存することは皮肉であり、基本的に目的を損なうことを認識していますが、これは私が思いつくことができる最善の方法であり、私のニーズに合っています。

これは、特にpeerDepsのサポートに非常に役立ちます。 ありがとうございました。

この機能にはいくつかの良い議論があります。 それはデフォルトで行うのとは異なり、人々はそれを必要としている人々だけがそれを使用するという明確な旗の後ろにあることを求めています。 現在、他のいくつかのように、保存したくない他のライブラリバージョンでCI中にいくつかのテストを行う必要があり

yarn install xxx 、次にyarn remove xxxます。

このユースケースがこれまでに議論されたかどうかはわかりません。 私の状況を説明してみましょう。1つのリポジトリで相互に依存しているパッケージがたくさんあります。 それらはすべて同じ外部依存関係を使用し、その下のルートサービスサブプロジェクトで共通のパッケージを使用します。各ローカルパッケージは、次に使用する順序でビルドする必要があります。 私はこれに糸のワークスペースを使おうとしています。 まず、ルートpackage.jsonにローカルパッケージが定義されていません。 すべてのコンポーネントを構築する1サイクルが完了すると、ローカルの依存関係を持つ完全に更新されたルートpackage.jsonが作成されます。 この更新されたものがCI上に構築されると、追加されたすべてのローカルパッケージは、可用性がないために失敗します。 CIで機能させるには、これらの新しく追加されたエントリを削除する必要があります。

yarn install xxx 、次にyarn remove xxxます。

同じ

これを実行できるようにするためのユースケースは次のとおりです。

ツール内の「アプライアンス」用のモジュラーエコシステムを備えたツールを構築しており、ローカルインスタンスをそれらのアプライアンスでセットアップし、構成を介して動的にアクティブ化することを計画しています。 アプライアンスはnpmに公開されます（誰かが必要な場合は、フレームワークの外部で呼び出すことができます）。

バニラプロジェクトはこれらのパッケージに依存しないため、 package.json保存することは不適切です。 特定のインスタンスの構成では、パッケージの1つをローカルにインストールする必要がある場合があります。

この機能がないことは、私たちのプロジェクトにとって制限的な決定であるように思われますが、代替アプローチを引き続き検討します。

ここで「メンテナ」の返事を読む前は、私はこれまでで最も頑固な人だと思っていました。

ほぼ4年...🤦

「頑固さ」は「デザインビジョンを持ち、誰もが求めるものすべてを実行しない」ことと同じではありません。

「頑固さ」は「デザインビジョンを持ち、誰もが求めるものすべてを実行しない」ことと同じではありません。

デザインビジョンはハッピーパスを説明し、ここで要求されたものとしてハッチを脱出し、より広いコミュニティの有用性を高めます。

「フリーフォーム」のインストールを追跡するセクションと現状の増分スナップショット（ node_modules ）をロックファイルに追加して、それらを安全に元に戻せるようにしないのはなぜですか？ または、node_modulesとは別のフォルダーに依存関係を置き、node_modulesを使用してリンクをパッケージに公開し続けると、Yarnは実際に自分で管理でき、目に見えないインストールが上書きされたり壊れたりする心配はありません。

Gitはあなたの数十年前にこの問題を解決しました、追いついてください！ 何かを思い付くだけです！ それが設計です-制限と戦う（または制限に屈する）のではなく、制限を回避します。

ここの両端のトンネルビジョンは、無知、考えすぎ、そして不必要な二極化から生まれています。 武道や哲学、革命や政治はありません。 ただのツール、たくさんのコード、そしてやるべき仕事があります。 ツールが仕事を成し遂げるのを助けることができないならば、それはその特定のシナリオのためのツールではありません。 そして、Yarnのように、交換で完全な汎用であると称するツールの場合、ここでは無視されている一般的なシナリオが非常に多いため、単に独自の墓を掘っています。

狭い丘を一周できると、みんなが押し合っているような気がします。