適切なi7を搭載したSSDを使用して、Windows10のこのhttps://github.com/macdja38/pvpsite/blob/master/package.jsonで依存関係のリンクに200秒以上かかるようにしてい

パフォーマンスの問題は、Windows Defenderが原因である可能性があり、無効にしていますが、200秒を50に近い値に減らすことはお勧めできません。

セキュリティを下げるよりも良い解決策があるはずだと思います。

他の一部のユーザーは、プロジェクトのルートディレクトリでのみ無効にすることが機能することを確認していますが、それを実行しようとしたときにWindows Defenderが少し壊れたため、確認できません。

約30の依存関係を持つgitリポジトリの問題についても同じことが言えます。
ウィンドウズ10
ノードv5.5.0
糸0.16.1

Windows Defenderを無効にすると、リンク時間が大幅に短縮されます

おそらくこのPRによって「解決」されるべきでしょうか？

残念ながら、ここでできることは多くありません:(ウイルススキャナーはすべてのファイルをスキャンし、npmエコシステムには多くの小さなファイルがあります。小さなファイルは通常、EXT4やZFSなどの他のファイルシステムと比較してNTFSで少しオーバーヘッドがあります。しかし、それはウイルススキャナーによって悪化します。

そうは言っても、Yarnはnpmよりも高速である必要がありますが、LinuxやMacほど高速ではありません。

ウイルス対策スキャナーがインストールされていないMacを使用しています。 しかし、単純なangular-jsアプリでもリンクにかなりの時間がかかるという、同じ問題がまだ発生しています。

私もこの問題を抱えています。 Ubuntuでは174秒かかりました。

0.17.8から0.17.19にアップグレードして初めて、この問題が発生し始めました。 ウイルス対策のないMac。

奇妙なことに、パッケージを削除するたびにリンクプロセスをスローする必要があります。 Npmはそれをより速く行います。 そして、リンクには本当に長い時間がかかります。

これは、このpackage.json（Heroku上）で再現できます。

{
  "name": "yarn-link-slowness",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "axios": "^0.15.3",
    "lodash": "^4.17.2",
    "react": "^15.4.1",
    "react-dom": "^15.4.1",
    "react-player": "^0.12.1",
    "react-redux": "^4.4.6",
    "react-router": "^3.0.0",
    "react-router-redux": "^4.0.7",
    "react-scripts": "^0.8.4",
    "redux": "^3.6.0",
    "redux-auth-wrapper": "^0.9.0",
    "redux-logger": "^2.7.4",
    "redux-promise-middleware": "^4.2.0",
    "redux-thunk": "^2.1.0"
  },
  "engines": {
    "node": "7.2.1",
    "yarn": "0.17.8"
  }
}

糸0.17.8の場合、取り付けには37秒かかります。 ヤーン0.17.10の場合、インストールには97秒かかります。 その他の変更はありません（毎回新しいHerokuアプリ）。

✨45.10秒で完了しました。

    "autoprefixer": "6.3.6",
    "babel-core": "6.7.6",
    "babel-jest": "13.0.0",
    "babel-loader": "6.2.4",
    "babel-plugin-transform-class-properties": "6.9.1",
    "babel-plugin-transform-object-rest-spread": "6.8.0",
    "babel-preset-es2015": "6.6.0",
    "babel-preset-react": "6.5.0",
    "bluebird": "3.3.5",
    "cardmask": "github:aj0strow/cardmask#v1.0.0",
    "chai": "3.5.0",
    "classnames": "2.2.5",
    "copy-webpack-plugin": "2.1.3",
    "core-js": "2.4.1",
    "css-loader": "0.23.1",
    "enzyme": "2.3.0",
    "file-loader": "0.8.5",
    "force-case-sensitivity-webpack-plugin": "0.1.1",
    "jest": "13.0.0",
    "jest-cli": "13.0.0",
    "json-loader": "0.5.4",
    "lodash": "4.11.1",
    "moment": "2.13.0",
    "ms": "0.7.1",
    "node-sass": "3.4.2",
    "postcss-loader": "0.9.1",
    "raw-loader": "0.5.1",
    "react": "15.2.0",
    "react-addons-css-transition-group": "15.2.0",
    "react-addons-test-utils": "15.2.0",
    "react-css-transition-replace": "2.0.1",
    "react-dom": "15.0.1",
    "react-redux": "4.4.5",
    "react-router": "2.3.0",
    "react-textarea-autosize": "4.0.3",
    "recompose": "0.20.2",
    "redux": "3.5.1",
    "redux-actions": "0.10.0",
    "redux-thunk": "2.0.1",
    "reselect": "2.5.3",
    "sass-loader": "3.2.0",
    "sinon": "1.17.4",
    "style-loader": "0.13.1",
    "webpack": "1.13.0",
    "webpack-dev-server": "1.14.1",
    "whatwg-fetch": "1.0.0",
    "zxcvbn": "4.3.0"

誰かが「依存関係のリンク」ステップでヤーンが何をするのかを正確に説明できますか？
このステップの最大数は、異なるマシン上の同じプロジェクトで最大1000から最大65000まで変化するためです。 この数字はどういう意味ですか？

この問題もあります。 yarn add依存関係を追加すると、「依存関係のリンク」がトリガーされるようで、永遠にかかります。 今のところnpmに戻らなければなりませんでした。

ノード：6.9.2
OS：Windows 10

ノード：7.3.0
OS：Windows 10 64
わたしも

こっちも一緒。 リンク23420 ...何か、そして良い日に約1分半かかります。

糸0.19.1
NodeJS 7.3.0
ウィンドウズ10

yarn add momentは105秒かかります。 依存関係はありません。 ：/

編集：Windows Defenderをオフにすると、時間が最大30秒から最大50秒に短縮されます。 作業中のディレクトリを除外しようとしましたが、役に立たなかったようです。

create-react-appの新しいコピーを実行しただけで、876.37秒かかりました。 アンチウイルスの動作を制御できないことは理解していますが、NPMとCRAの使用経験はWindowsの方がはるかに高速でした。

Windows 10では、一般的なアドバイスとしてUbuntubashシェルを使用してください。

Windows 10では、一般的なアドバイスとしてUbuntubashシェルを使用してください。

Linux用のWindowsサブシステムではディスクI / Oが非常に遅いため、現時点では既知の制限です。

しかし、NPMとCRAでの私の経験は、Windowsではるかに高速でした。

@ JeffBaumgardt-興味深い... YarnはWindowsでは遅いですが、それでもnpmより速いはずです！

@ Daniel15おそらくそうあるべきですが、そうでnpm add <packages> --save-devを実行し、yarn.lockを削除してyarnを実行します。これは、 yarn add <packages> -Dを1回実行するよりも高速です。 もちろん、ロックを削除して、バンドルをアップグレードするように強制したくはありません。 代わりに、以下は素晴らしいものでした：

cc @echobnet

Windows 10 + WindowsDefenderを使用しているすべての人

1. ファーストクリック設定

   

2. 除外まで下にスクロールします

   

3. yarn cache dirを実行して、キャッシュフォルダーの場所を取得します

   • このキャッシュフォルダを除外リストに追加します
   • プロジェクトのnode_modulesフォルダーを除外リストに追加します

4. 反応プロジェクトのスピードアップx3-10

@SleeplessByteまたは、除外されたプロセスにyarnとnodeを追加するだけです。

Windowsだけの問題ではありません。 私は私のMacProで恐ろしいリンクタイムを見てきました。

OS：OS X 10.11.6（El Capitan）
ノード：7.6.0
毛糸：0.20.3

Mac10.12.3でも_非常に_遅いことを確認できます。 ウィンドウとは関係ありません。

そして、私のセットアップはこのスレッドの他の人よりも_way_遅いようです。 小さなプロジェクトでは、yarnが約600.000個のファイルをリンクしようとすることがあります。 これには30分以上かかる場合があります。 私は現在、クリーンキャッシュと毎晩（v0.22.0-20170226.1626）でそれを試しています。 特定のスコープパッケージには、公式レジストリとカスタムプライベートレジストリを使用しています。 ただし、私の同僚はこの問題に悩まされていないので、カスタムプライベートレジストリが問題になるとは思いません（とにかくパッケージのフェッチはすでに完了しています）。 package.json 、 path:プロトコルを使用した相対ファイルもいくつかあります。

https://github.com/google/material-design-iconsのインストールに多くの問題がありhttps://github.com/google/material-design-iconsのインストールに私ほど問題はありません。

更新

よくわかりません... file:を含むパッケージをインストールすると、 node_modules/などを含むモジュールがキャッシュに配置されるように見えます。 すべてが独自のnode_modules/を含む複数の例がある場合、これは_本当に_問題です。 file:インストールでは、 .npmignoreなどが無視されているようです。 解決策がローカルで解決されたファイルをキャッシュしないことである場合、これはおそらくhttps://github.com/yarnpkg/yarn/issues/2165に要約されます。 私は私のキャッシュ（開いた場合は$ yarn cache dirモジュール用）と見て、なぜどこにインストールfile:とそれに含まれるnode_modulesディレクトリまたは他の大きなディレクトリを、私がスピードアップすることができますlinking phaseこれらのディレクトリを手動で削除して

[3/4] Linking dependencies...
Done in 947.71s. 

yarn add ...新しいパッケージを追加するには、この時間待つ必要がありました
Win7 / wヤーンv0.21.3
私のアプリでmaterial-design-iconsパッケージを取得しました。
これは関連していると思いますhttps://github.com/yarnpkg/yarn/issues/990

@kuncevichすべてが私の側で

@kuncevic Windowsで見つけたバグの影響を受ける可能性があります： https ：

基本的に、yarnは、すべての操作で常にnode_modules内のすべてのファイルをコピーできます。

私の場合、 @ asolopovasはnode.exeように10-26 %です：

完全にオフにしても、AVは問題ありません。糸の速度の改善は見られません。

ノード-v 6.9.2

@kuncevicはノードを7に更新し、それが処理を高速化するかどうかを確認します。そうでない場合、

基本的に、yarnは、すべての操作でnode_modules内のすべてのファイルを常にコピーできます。

@vbfox理由について詳しく

@danpalmerリンクフェーズは、基本的に3つの大きなステップで機能します。

1. node_modulesある必要があるすべてのファイルを検索します
2. このリストとすでに存在するものを確認し、キャッシュからnode_modulesコピーする必要があるものを見つけます
3. コピーを行う

libuv / nodejsのバグ（ utimeはyarnによって使用され、バグはミリ秒をゼロに設定することです）のため、前回の実行でyarnによってコピーされたファイルは常に異なることがわかります（キャッシュ内のバージョンには通常の変更時間ですが、node_modules内のすべてのファイルのバージョンはミリ秒単位ではないため、フェーズ2では常にすべてが変更されたことが報告されます。

バグはノード7.1で修正されているため、LTSに限定されていない場合、修正は非常に簡単です（ファイルはバグのあるutime作成されているため、リポジトリでの最初のヤーン操作は遅くなりますが、以下はすべてはるかに高速です）。 私のPRは基本的に、Windowsのファイル時間のミリ秒部分を比較するときに無視することでこれを修正しています。

パッケージ全体のコピーに関しては、現在のファイルシステムに存在する操作ではありません。すべてファイルレベルで機能します。
提供される最高のウィンドウはFileCopyAPI（yarnで使用するPRがあります：https：//github.com/yarnpkg/yarn/pull/2960）ですが、ネイティブのnodejsストリームAPIを使用するよりも少し高速です。

シンボリックリンクに関しては、なぜそれが行われないのかわかりませんが、javascriptパッケージマネージャーについて十分な知識がありません（テストフォルダーの削除など、パッケージファイルにいくつかの変更が加えられていますが、個々のファイルをシンボリックリンクしても違いはありません）しかし、linux / macosでもそうではないので（Windowsよりもはるかに一般的です）、正当な理由があるかもしれません。

Node 7.8.0アップグレードした私の実験： https ：

1. Find every file that need to be in node_modules
2. Check this list versus what is already there and find what need to be copied around from cache to node_modules
3. Do the copy

ほとんどの場合、ブランチを切り替えるときにライブラリのスワスを再リンクしていることを考えると、これを行うためのより良い方法があるのではないでしょうか。

node_modulesビルドごとに一意のIDを作成し、キャッシュからディレクトリ全体をシンボリックリンクできますか？ このように、ブランチを前後に切り替えることは、実際には異なるnode_modulesシンボリックリンクするだけです。

確かに、実行したnode_modulesすべてのバージョンをキャッシュしているので、ディスクに大量の書き込みを行うことになりますが、ディレクトリへのシンボリックリンクを最適化して、実際にのみ実行できるようにすることはできますか？シンボリックリンクのツリーを保存しますか？

ナイーブであることを許してください。UNIXやそれ以下のWindowsファイルシステムに関しては、私は最も教育を受けていませんが、教育的な演習としてこれを掘り下げて、明らかに欠陥がない場合は、このアイデアの概念実証。

pnpmとIED採用あなたは私が思うに言及技術のいくつかではなく、完全に確認してください、いくつかの時間前にそれらを試してみましたが、彼らはどちらかのWindows上での問題の原因となったり、糸のように高速ではありませんでした。

私も糸でアプリを作成するのに非常に長い時間がかかりました
Windows Server 2012
ノード7.9.0
糸0.22
554.08秒で完了。

ただし、Reactのインストールが含まれていない場合は、はるかに高速です。

最近、リンク時間が長くなることはありません。 ランニング
毛糸- v0.23.2
ノード- 6.10.2または7.9.10 （nvmを使用して切り替え）

Macとarchlinux（Manjaro）でこれを試しました

Windows Defenderの除外にノードとヤーンを追加すると、Windowsマシンでのリンク時間が約60％短縮されたことを確認できます。

+1

[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 180.22s.

ノード7.9.0に切り替えても、速度は上がりませんでした。 'yarn'、 'node'、および 'npm'をWindowsDefenderに追加すると（.exe拡張子の有無にかかわらず、何が必要かわからない）、3倍高速化されましたが、npmインストールよりも50％長くなりました。

また、ノードで実行されているものやインストールされているパッケージからすべての保護を削除することは、私には良い考えではないようです...

私の経験を追加する-node.exe / yarn.exeをWindowsDefenderの例外リストに追加すると、yarnのインストール時間が半分になります（60秒から30秒）。

私もこれを見ていますが、単一のパッケージを更新するのに非常に時間がかかるため、パッケージの開発中にすばやく反復するのはイライラします。

yarn install v0.24.5
[1/4] Resolving packages...
[2/4] Fetching packages...
warning [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
Done in 338.20s.

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:    14.04
Codename:   trusty

  "dependencies": {
    "autoprefixer": "^6.7.7",
    "axios": "^0.16.1",
    "babel-core": "^6.24.1",
    "babel-loader": "7.x",
    "babel-preset-env": "^1.4.0",
    "coffee-loader": "^0.7.3",
    "coffee-script": "^1.12.5",
    "compression-webpack-plugin": "^0.4.0",
    "css-loader": "^0.28.0",
    "element-ui": "^1.3.3",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.11.1",
    "glob": "^7.1.1",
    "js-yaml": "^3.8.3",
    "node-sass": "^4.5.2",
    "path-complete-extname": "^0.1.0",
    "postcss-loader": "^1.3.3",
    "postcss-smart-import": "^0.6.12",
    "precss": "^1.4.0",
    "rails-erb-loader": "^5.0.0",
    "rails-ujs": "^5.1.0",
    "sass-loader": "^6.0.3",
    "style-loader": "^0.16.1",
    "turbolinks": "^5.0.3",
    "vue": "^2.3.0",
    "vue-loader": "^12.0.2",
    "vue-router": "^2.5.3",
    "vue-template-compiler": "^2.3.0",
    "webpack": "^2.4.1",
    "webpack-manifest-plugin": "^1.1.0",
    "webpack-merge": "^4.1.0"
  },
  "devDependencies": {
    "element-theme": "*",
    "element-theme-default": "^1.3.3",
    "eslint": "^3.19.0",
    "eslint-config-airbnb": "^14.1.0",
    "eslint-plugin-import": "^2.2.0",
    "eslint-plugin-jsx-a11y": "^4.0.0",
    "eslint-plugin-react": "^6.9.0",
    "nodemon": "^1.11.0",
    "webpack-dev-server": "^2.4.5"
  }

:(

ヤーン0.24.5、ノード7.10.0、およびnpm 4.2.0を使用して、2010年真夏のMacBook Pro（Sierra 10.12.4）に+1を追加します。

λヤーンはブートストラップサスを追加します
糸はv0.24.5を追加します
[1/4]🔍パッケージを解決しています...
[2/4]🚚パッケージの取得...
[3/4]🔗依存関係のリンク...
[4/4]📃新しいパッケージを作成しています...
成功保存されたロックファイル。
成功1つの新しい依存関係を保存しました。
└─ [email protected]
✨123.52秒で完了。

"dependencies": {
    "@angular/animations": "^4.1.3",
    "@angular/common": "^4.0.0",
    "@angular/compiler": "^4.0.0",
    "@angular/core": "^4.0.0",
    "@angular/forms": "^4.0.0",
    "@angular/http": "^4.0.0",
    "@angular/material": "^2.0.0-beta.5",
    "@angular/platform-browser": "^4.0.0",
    "@angular/platform-browser-dynamic": "^4.0.0",
    "@angular/router": "^4.0.0",
    "bootstrap-sass": "^3.3.7",
    "core-js": "^2.4.1",
    "font-awesome": "^4.7.0",
    "material-design-icons": "^3.0.1",
    "materialize-css": "^0.98.2",
    "rxjs": "^5.1.0",
    "zone.js": "^0.8.4"
},
"devDependencies": {
    "@angular/cli": "1.0.1",
    "@angular/compiler-cli": "^4.0.0",
    "@types/jasmine": "2.5.38",
    "@types/node": "~6.0.60",
    "codelyzer": "~2.0.0",
    "jasmine-core": "~2.5.2",
    "jasmine-spec-reporter": "~3.2.0",
    "karma": "~1.4.1",
    "karma-chrome-launcher": "~2.0.0",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^0.2.0",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.1.0",
    "ts-node": "~2.0.0",
    "tslint": "~4.5.0",
    "typescript": "~2.2.0"
}

npm installに戻すと、修正されました。-u'stream '：u' [3/4]ヤーンの依存関係をリンクし、NPMでエラーは発生しませんでした。

おそらく最新のビルドで問題が発生しました

Dockerを介してこれを実行します。

@iwarner npm5.0は良い選択です。

私はVagrant（Ubuntu Xenial）とJenkinsで糸を走らせています。 package.jsonには2つのサブプロジェクトがあります。
npm -v 3.10.10
ノード-v6.10.1
ヤーンインストールv0.21.3

npmのインストールにタイムアウトの問題（4時間では不十分）があったため、しばらく前にnpmからyarnに切り替えました。

現在、糸は約30％の時間で機能しますが、70％の時間では、ある時点で4時間のタイムアウトが発生します。 最初のヤーンのインストール、または2番目のヤーンのインストール、または単体テスト（jest）の実行中にタイムアウトになる可能性があります。

これはhttps://github.com/yarnpkg/yarn/issues/990の複製であり、比較チャートがあり、Yarnの最新バージョンがそこである程度の進歩を遂げたようです。
それでも問題が解決しない場合は、再現手順と最新のnpmとの比較を含む新しい問題を提出してください

success Saved lockfile.
Done in 1737.79s.

Ubuntu 16.04
i5、8 GB RAM

:(

Windows 10 v 1709 + SSD + PowerShell +ノード6.12.2：
ヤーンのインストールは最後のパッケージまで高速で、プレインストールコマンドでスタックしているようでした。
こちらの手順に従ってWindowsDefenderの除外を追加しましたが、ソースを％USERPROFILE％sourceにチェックアウトしたため、大幅に速度が低下しました。 cでチェックアウト：ヒープが高速でした。

Ubuntuプラットフォームのソリューションはありますか？ パッケージを追加する前に、文字通りよく考えなければなりません。

Ubuntuは私にとって超高速で、速度はまったくありません。

2018年2月23日金曜日、11：13 Basant Besra、 notifications @ github.comは次のように書いています。

Ubuntuプラットフォームのソリューションはありますか？ 私は文字通り前に二度考えなければなりません
パッケージを追加します。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/yarnpkg/yarn/issues/1496#issuecomment-367897260 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAcMheTtAYOsXcrnej_f2F8bY5D3nDT2ks5tXizngaJpZM4Kh3OZ
。

これは非常に迷惑です。 モジュールの1行を文字通り変更し、新しいバージョンで再公開したところ、 yarn add moduleに5分以上かかりました。

テキストエディタを使用してパッケージを手動で更新するだけの方が速いでしょう

私もこの問題を経験します：

success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ @material-ui/[email protected]
info All dependencies
└─ @material-ui/[email protected]
Done in 93.43s.

私のシステムはLinux manjaro 4.14.31-1-MANJARO #1 SMP PREEMPT Wed Mar 28 21:42:49 UTC 2018 x86_64 GNU/Linux

NodeJS：v9.9.0
糸：v1.5.1

私にとっても超遅いDone in 254.32s.

ノードv8.10.0
npm 5.6.0

OSX 10.11.6（15G19009）

私は[email protected]に切り替えうまく機能しています。

ほとんどの場合、この問題を回避するためにオフラインキャッシュ機能を使用していますが、package.jsonまたはyarn-lockfileが変更されるとすぐに、この問題に戻ります。 Linuxマシンではリンクに10分かかります。 これはWindows固有ではないと思います。

これは間違いなくWindowsだけの問題ではありません（Windows以外のマシンの人々からのすべての投稿から明らかなはずです）！

私はmacOSHigh Sierra 10.13.4を使用しており、ノード10.1.0（npm 5.6.0）とyarn1.6.0を使用しています。 ヤーンを使用して、依存関係をインストールするのに約40秒かかりました。 npmに切り替えたところ、約10秒かかりました。 とりあえずnpmに固執します。

CentOS7ボックスについても同じです。 これに関する更新はありますか？
糸：v1.7.0
npm：v5.7.1

それはノード10のMacの1.9.2で私に起こっています

macOS HighSierraを使用している私にとって、AvastFileShieldが問題の原因でした。 which yarnを使用して、yarn実行可能ファイルを除外パスとして追加しました。 今は大丈夫のようです。戻ってきたら更新します。

それはノード10のMacの1.9.2で私に起こっています

こっちも一緒。 High Sierraのヤーン1.9.2、ノード10.6.0。

@bestanderこれはWindowsの問題ではありません。 MacでYarn1.9.4を使用して再現できます。 この問題は再開する必要があります。

@davidgoli 、新しい問題を開く方がよい、これは新しい問題であり、個別にトリアージする必要があります

毛糸は、私が実行したどの環境でもかなり遅いです。 Debian、Mac、Windows。 新しい問題は開いていましたか？ またはnode_modulesを取り除くRFCはこれを解決しますか？

同じ問題があり、すでにnpmに切り替えていますが、まだバグがあります

ヤーンにも同じ問題があります。 解決策は見つかりましたか？

これは＃990の複製であり、比較チャートがあり、最新バージョンのYarnがそこである程度の進歩を遂げたようです。
それでも問題が解決しない場合は、再現手順と最新のnpmとの比較を含む新しい問題を提出してください

これは重複ではなく、この問題はWindowsだけに関係するものではありません。 新しい問題を開くと、コンテキストが失われます。

私は同じ問題を抱えています！

yarn install
yarn install v1.16.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[###############################################---------------------------------------------------------------------------------------------] 22778/67399

Done in 179.59s.

MacOS / Docker

Vagrant 2.2.4
ゲスト： Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)
ホスト： MacOS 10.14.5 Mojave

糸1.16.0
npm 6.9.0

MacBook Pro（Retina、13インチ、2015年初頭）
プロセッサー2.7GHz Intel Core i5
メモリ16GB 1867 MHz DDR3

yarn install v1.16.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 1552.45s.

実際、25分以上の生産性を失うことなくyarn installを実行することはできません。 それはばかげている。 これがWindowsの問題だとは思いません。 仮想化環境で実行すると、問題が発生する可能性が非常に高くなります。 おそらく、同期されたフォルダ/ゲストOSでのファイルの状態の確認に関係していますか？

糸v1.17.3
ノードv10.16.3
npm 6.9.0

ウィンドウズ

アプリプロジェクトフォルダーの場所をyarn cache dirと同じディスクセクションに配置しようとしました。
ヤーンキャッシュディレクトリ-> C：ユーザーAppDataLocalYarnCachev4

結果：
古い場所-> D：myApp Done in 747.17s.
新しい場所-> C：myApp Done in 488.97s.

CとDは同じ物理ディスクです。

マック

ただし、MacはWindowsよりも高速ですDone in 121.37s

ボトルネックはディスクの読み取り/書き込み速度だと思いますか？

OS X 10.15
糸v1.22.4
ノードv12.13.0
npm v6.12.0

私はまだこれを経験しています。 プロジェクトは、マウントされた暗号化されたディスクイメージにあります。 単一のパッケージのインストールには、比較的小さいpackage.json数分かかります。 ベンチマークは行っていませんが、npmの方がはるかに高速です。

編集：yarnのデフォルトのキャッシュフォルダを同じ暗号化されたボリュームに変更すると、これが修正されたことがわかりました。

これにも見舞われて、私は走っています：

OS：Ubuntu 18.04.2
毛糸：1.22.4
ノード：14.7.0
NPM：6.14.7