您要请求_feature_还是报告_bug_?
虫子
目前的行为是什么?
安装依赖项时,第三步: linking dependencies
花费很长时间,即使是单个软件包
如果当前行为是错误,请提供重现步骤。
预期的行为是什么?
请提及您的node.js,yarn和操作系统版本。
节点:6.7.0
作业系统:Windows 10
我使用Windows 10上的https://github.com/macdja38/pvpsite/blob/master/package.json链接了依赖关系需要200秒钟以上的时间,而i7的SSD则不错。
似乎性能问题可能是由Windows Defender引起的,将其禁用,同时可能不建议将其减少200s到接近50的某个位置。
我认为应该有一个比降低安全性更好的解决方案。
其他一些用户已经确认仅在项目的根目录中禁用它是可行的,但是我无法确定Windows Defender在尝试这样做时会自行崩溃。
我对git repo有大约30个依赖项的问题也有同样的看法。
Windows 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时,安装时间为37s。 使用纱线0.17.10,安装需要97秒。 没有其他更改(每次都有新的Heroku应用程序)。
in完成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
作业系统:Windows 10
节点:7.3.0
操作系统:Windows 10 64
我也是
同样在这里。 链接23420 ...某物,在美好的一天大约需要一个半分钟。
纱0.19.1
NodeJS 7.3.0
Windows 10
yarn add moment
需要105秒。 它没有依赖性。 :/
编辑:关闭Windows Defender确实可以将时间减少到〜30至〜50秒。 我尝试排除正在使用的目录,但这似乎无济于事。
刚刚运行了一个create-react-app的新副本,这花费了876.37s。 我知道您对防病毒的工作方式没有太多/任何控制权,但是我在Windows上使用NPM和CRA的经验要快得多。
在Windows 10上,只需使用Ubuntu bash shell作为一般建议即可。
在Windows 10上,只需使用Ubuntu bash shell作为一般建议即可。
在Linux的Windows子系统中,磁盘I / O非常慢,这是目前已知的限制
但是我在Windows上使用NPM和CRA的经验要快得多。
@JeffBaumgardt-有趣的...在Windows上,纱线的速度较慢,但仍应比npm快!
@ Daniel15它可能应该是,但是不是。 节点安装和卸载对我来说较小。 所以我会做npm add <packages> --save-dev
,删除yarn.lock并运行yarn,这比一次运行yarn add <packages> -D
快。 现在,每个人都在忙碌中,当然,我不想删除该锁并强迫每个人升级其捆绑包。 相反,以下情况很棒:
抄送@echobnet
首次点击设置
向下滚动到排除项
运行yarn cache dir
获取缓存文件夹的位置
加快反应项目的速度x 3-10
@SleeplessByte或者您可以简单地将yarn
和node
到排除的进程中。
不仅仅是Windows上的问题。 我一直在Mac Pro上看到可怕的链接时间。
作业系统:OS X 10.11.6(El Capitan)
节点:7.6.0
纱:0.20.3
我可以确认它在Mac 10.12.3上也很慢。 与Windows不相关。
似乎我的设置比该线程中的其他设置慢。 在小型项目中,yarn有时会尝试链接约600.000个文件。 这可能需要30多分钟。 我目前尝试使用干净的缓存并每晚(v0.22.0-20170226.1626)进行尝试。 对于某些作用域软件包,我使用官方注册表以及自定义私有注册表。 但是,我的同事们不会遭受这个问题的困扰,因此我认为自定义私有注册表不是问题所在(无论如何,获取软件包已经完成)。 在package.json
我们还有一些带有path:
协议的相对文件。
我在安装https://github.com/google/material-design-icons时遇到很多问题,其中包含_很多小文件_似乎对其他人也很麻烦(https://github.com/google/材料设计图标/问题/ 518)。 我不知道我的硬件是否坏了,无法处理很多小文件或类似的文件,或者是否与之相关。 同样,我的同事在安装https://github.com/google/material-design-icons时也没有遇到太多问题。
更新资料
我不确定...看起来像安装带有file:
的软件包一样,它会将包含node_modules/
和其他内容的模块放入缓存中。 如果您有多个都包含自己的node_modules/
示例,这将是一个问题。 似乎.npmignore
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上发现的bug的影响: https :
本质上,yarn始终可以为每个操作复制node_modules
中的每个文件。
@asolopovas在我的情况下是node.exe
像10-26 %
:
即使完全将其关闭,我的AV也不是问题,我看不到任何纱线速度的提高。
节点-v 6.9.2
@kuncevic将您的节点更新为7,并检查它是否使速度更快,否则@vbfox指向正确的方向。
本质上,yarn始终可以为每个操作复制node_modules中的每个文件。
@vbfox您能否详细说明原因? 我正在查看yarn的详细输出,发现几乎所有时间都花在了创建目录和复制文件上,因为似乎每个人都在做,而不是说为每个_package_创建一个目录然后复制整个程序包,应该快一些,甚至只是符号链接所有可能更快的程序包。 这些不安全吗?
@danpalmer链接阶段主要通过3个主要步骤进行:
node_modules
node_modules
由于libuv / nodejs错误(yarn使用utime
,错误是将毫秒设置为零),在上一次运行中,yarn复制的文件始终被发现是不同的(缓存中的版本具有正常的修改时间,但是node_modules中的所有文件的版本都是零毫秒),因此阶段2始终报告所有更改。
由于该错误已在节点7.1中修复,因此如果您不仅仅限于LTS,也很容易修复(由于回购文件是使用错误的utime
创建的,因此在回购协议上的第一个yarn操作会很慢,但是以下所有操作都是快很多)。 我的PR本质上是通过比较Windows时忽略文件时间的毫秒部分来解决此问题的。
关于复制整个软件包,这不是当前文件系统AFAIK上存在的一项操作,它们都可以在文件级别上工作。
最好的窗口提供的是FileCopy API(我有一个PR可以在yarn中使用它: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文件系统不感兴趣时,但我很乐于对此进行深入研究,作为一项教育活动,并尝试提供一个这个想法的概念证明,如果它没有任何明显的缺陷。
我也只是用了很长的时间来用纱线创建反应应用程序
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排除项中添加节点和yarn可以将Windows计算机上的链接时间减少60%左右。
+1
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 180.22s.
切换到节点7.9.0并没有加快我的速度。 在Windows Defender中添加“ yarn”,“ node”和“ npm”(带有和不带有.exe扩展名,不确定需要什么)确实为我提高了3倍,但仍比npm安装长50%。
对我来说,从节点中运行的任何内容或正在安装的任何软件包中删除所有保护似乎也不是一个好主意...
添加我的经验-将node.exe / yarn.exe添加到Windows Defender的例外列表中,使我们的纱线安装时间减少了一半(从60s到30s)。
我也看到了这一点,这使得开发软件包时快速迭代变得令人沮丧,因为更新单个软件包需要很长时间。
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]
in完成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]链接yarn中的依赖项,而NPM中没有错误。
最新版本可能出了点问题
通过Docker运行它。
@iwarner npm 5.0是一个不错的选择。
我在Vagrant(Ubuntu Xenial)和Jenkins经营纱线。 package.json有两个子项目。
npm -v 3.10.10
节点-v 6.10.1
纱线安装v0.21.3
一段时间前,我们从npm切换到yarn,因为npm安装存在超时问题(4小时不足)。
现在,纱线大约有30%的时间起作用,但是在70%的时间中,我们有时会出现4小时超时。 它可能是第一次安装纱线,或者是第二次安装,或者我们可能在运行单元测试(玩笑)时超时。
这是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:
纱线安装非常快,直到最后一个软件包,似乎卡在了预安装命令上。
按照此处的说明为Windows Defender添加排除项,但是我也将我的源签出到%USERPROFILE%source中,这大大降低了它的速度。 在c中检出:堆速度更快。
有针对Ubuntu平台的解决方案吗? 我真的需要三思而后行添加一个软件包。
Ubuntu对我而言超级快,一点都不慢。
2018年2月23日星期五,Basant Besra,11:13, notifications@ github.com写道:
有针对Ubuntu平台的解决方案吗? 我真的必须三思而后行
添加一个包。-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件,在GitHub上查看
https://github.com/yarnpkg/yarn/issues/1496#issuecomment-367897260或静音
线程
https://github.com/notifications/unsubscribe-auth/AAcMheTtAYOsXcrnej_f2F8bY5D3nDT2ks5tXizngaJpZM4Kh3OZ
。
这太烦人了。 我从字面上更改了模块中的一行,将其重新发布到新版本中, 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计算机上的人们的所有帖子中都可以看出来!)
我在macOS High Sierra 10.13.4上,使用节点10.1.0(npm 5.6.0)和yarn 1.6.0。 使用yarn,安装依赖项大约需要40秒钟。 我切换到npm,大约花了10秒钟。 我暂时坚持使用npm。
同样对于我们的centos 7盒子。 有任何更新吗?
纱线:v1.7.0
npm:v5.7.1
这是我在节点10上的Mac上的1.9.2上发生的
对我来说,在macOS HighSierra上,Avast FileShield引起了问题。 我已经使用which yarn
将yarn可执行文件添加为排除路径。 现在看来还可以,如果返回,我会进行更新。
这是我在节点10上的Mac上的1.9.2上发生的
同样在这里。 纱线1.9.2,高山脉上的节点10.6.0。
@bestander,这不是Windows问题。 我可以在Mac上使用Yarn 1.9.4进行复制。 此问题应重新打开。
@davidgoli ,最好打开一个新期刊,这是一个新期刊,应分开分类
在我运行的任何环境下,纱线的运行速度都很慢。 Debian,Mac,Windows。 新的问题是开放的吗? 还是摆脱了node_modules的RFC可以解决这个问题?
我有同样的问题,已经切换到npm但仍然有bug
我也有纱线问题。 找到任何解决方案吗?
这是#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
流浪汉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.7 GHz Intel Core i5
内存16 GB 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
我试图将我的App项目文件夹位置与yarn cache dir
放在同一磁盘部分。
纱线缓存目录-> C:Users
结果:
旧位置-> 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感觉更快。
编辑:原来,将纱线的默认缓存文件夹更改为同一加密卷上的问题已为我解决。
刚刚也受到了打击,我正在跑步:
作业系统:Ubuntu 18.04.2
纱:1.22.4
节点:14.7.0
NPM:6.14.7
最有用的评论
我在Mac上没有安装任何防病毒扫描程序。 但是我仍然看到相同的问题,即使使用简单的angular-js应用程序进行链接也要花费大量时间。