Yarn: 添加包而不保存到package.json

创建于 2016-11-09  ·  96评论  ·  资料来源: yarnpkg/yarn

似乎不接触package.json就不可能使用yarn安装软件包吗? (例如不带--save参数的npm install)。 不应添加此功能吗?

最有用的评论

我不明白为什么业主如此看待。 如果您没有看到它的用法,并不表示没有。 我相信,如果人们需要它,就意味着他们需要它,而且他们不一定是愚蠢的。
添加一个可选的--no-save选项可以解决某些人的问题,并且完全没有缺点。

所有96条评论

不,此功能是故意遗漏的。 安装软件包而不反映在package.json中被认为是危险的。 你为什么想要这样的事情存在?

Facebook公告

我们删除了npm install的“隐形依赖”行为并分割命令。 运行yarn add <name>等效于运行npm install --save <name>

我曾经经常使用该功能来测试事物。 尤其是在使用要维护的库并需要安装本地版本(创建file: dp)的库时,只是为了在创建发行版之前测试我的更改。

虽然我同意默认情况下npm的实现是一个糟糕的选择,但我认为这在明确使用时可以派上用场。

是的,我认为允许它与显式标志一起使用将是一件很不错的事,目前,该标志仍​​可以使用npm i =),但只是为了摆脱npm的需要。

我们明确不支持此操作,因为这是对node_module的必要更改,它将与随后的yarn install s抹去,因为我们认为package.jsonyarn.lock真理之源。

我们有一个无法轻易在Windows(libxslt)上安装的依赖项,因此:

  • 对于Windows:开发人员将其解压缩到他们的node_modues中
  • 对于Linux:开发人员无需保存即可安装(如果安装在package.json中,则使用Windows的开发人员将无法执行任何安装,因为构建会失败)

是否有使用纱线进行清洁的方法(或获得此结果的更好方法)?

(我同意您的观点,尽管软件包应该反映在package.json中,但是在这里我找不到任何干净的解决方案)

@GuillaumeLeclerc yarn add -D xxx并自己从package.json中删除条目怎么办?

下次添加另一个软件包时,它将被删除吗? 不是吗

@GuillaumeLeclerc不幸的是,是的。

@GuillaumeLeclerc您可能想清理您的评论...

请添加一个像yarn add --no-save这样的参数,这样我就可以安装模块而无需更改我的package.json或yarn.lock。 我经常发现自己需要在提交模块之前先进行测试。

我不能使用普通的npm install因为我得到“超出了最大调用堆栈大小”。 因此,纱线是唯一可行的安装方式。

请不要让我将更改还原为package.json yarn.lock!

对我来说,这很困扰我,因为我正在尝试安装peerDep。 Yarn无法在install期间安装对等部门,因此我必须手动执行。 如果没有将它添加到package.json / yarn.lock中,我将无法yarn add <package> 。 我被卡住了。

@viveleroi这听起来完全正确。 为什么要安装对等依赖项而不将其添加到package.json

@hpurmann因为它会将我的peerDependencies复制到dependencies (如果我使用--dev则复制到dependencies devDependencies --dev )。 如果那是预期的,那肯定不是直观的。

@hpurmann我想公开一个react组件,所以react应该是peerDep。 但是,我需要在项目中安装react才能进行开发。

只需添加--no-save =>非常重要
我需要跳过特定软件包的特定可选依赖项。 我用你的毛线做不到。 可能带有--no-save选项,我可以在周围工作

因为yarn link local-pkg不会在主机应用程序中安装local-pkg的依赖项,所以我想直接安装它们,但不将它们保存到应用程序package.json中,因为它们将在发布后由local-pkg带来。

我不明白为什么业主如此看待。 如果您没有看到它的用法,并不表示没有。 我相信,如果人们需要它,就意味着他们需要它,而且他们不一定是愚蠢的。
添加一个可选的--no-save选项可以解决某些人的问题,并且完全没有缺点。

我试图将Yarn用于在AWS Lambda上运行的NodeJS项目。 我很惊讶为什么不支持此功能。 我的用例是我需要在本地开发环境上安装aws-sdk,但我不希望将其保存在package.json因为AWS Lambda已经在其环境中安装了它。 包括aws-sdk意味着我们的最终软件包会肿。

纱线接头和纱线添加物不能一起生活。 yarn add取决于package.json,而yarn link只是将本地包链接到另一个位置。

假设您正在开发依赖于Y的程序包X,同时也是X和Y的开发人员,因此您将X和Y保留在本地并将Y链接到X的目录中。到Y的链接。

您如何解决这个问题?

〜在这种情况下,您可以简单地使用npm-commands进行安装,而无需在包json或yarn.lock上创建占用空间:〜

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

我在其中一个脚本中使用npm install ,该脚本将本地子模块的依赖项安装到主node_modules。 这在npm4上可以正常工作,但在npm5上却被完全破坏了,因为npm5只是决定在安装-.-的过程中对某些软件包进行核对(请参阅https://github.com/npm/npm/pull/18921)

因此,我试图用yarn替换脚本中的npm install ,但是如果安装过程中yarn总是碰到本地子模块的package.jsons,我真的不能这么做,至少没有我的剧本在凌乱之后变得安静凌乱,并且“清理”

您已经有--no-lockfile选项,因此它使node_modules文件夹变得无用,
但是开发人员仍然需要采用变通方法来保持package.json不可变。

谢谢。

我喜欢每次有人解释安装模块的特殊用例但不记录下来的方式时,维护人员会回来并朗诵他们的讲话。 如果您可以满足许多不同的人(来自遭受道德失败之苦的人)的相同要求,则必须使自己对自己的坚持感到容易自信。 作为一种折衷,也许我们可以将开关命名为--i-am-a-heritic-and-a-bad-programmer

悲伤,就看到了一个关键的缺陷yarn从蜜饯npm是其对抗他们的组织以外的任何人。

就我而言,我想将其用作#4297问题的解决方法:)
人为地限制开发人员执行操作可能会使您的产品在某些情况下无法使用。

你在开玩笑吗这是一种荒诞。 请停止说明每个开发人员工作流程应如何运作。 这正是NPM不适合我们而我们选择了Yarn的原因。 “ package.json和yarn.lock应该是真理的源泉”这一思想是荒谬的。 软件包应该是可安装的,而无需修改源代码。 就那么简单。

来吧,维护者。 显然,社区确实有此需求。 请停止使用未经过滤和放错位置的哲学关闭智能对话。

现在,我发现yarn破坏了我的测试,因为我有需要在其中测试require模块,并且为了进行测试,需要将示例模块提交到./node_modules 。 当我运行yarn install时,Yarn将删除示例模块。 我认为,更多的是“真理之源”。

用例:使用的工具需要包装。 团队不使用该工具。 团队(合理地)不希望安装该软件包。

我使用codelyzer编写角度样式指南时,这非常令人沮丧,但是我团队的其他成员却没有,并且对代码功能没有影响。 现在使它工作的唯一方法是将其添加到我的纱线锁中,并假设我的纱线锁没有实际更改,或者即使我的团队使用纱线也要使用npm。 这两个都是可怕的选择。

已经是2018年了,但是尽管有许多有效的用例,但尚未添加此功能。

再举一个为什么这可能有用的例子:

我们有一个脚本,可以通过安装新版本,运行测试然后将其保存到package.json / *.lock并提交更改或在出现错误时回滚来自动更新依赖项。 再次运行yarn而不是记住旧版本并再次显式adding更加容易。

此外,在“绝对”确保您能够真正更新此依赖项而不会破坏测试之前,不要更改您的单个真点( package.json )感觉更干净。 现在,您最终得到一个package.json (即使它是临时的),其中包含一个破坏您代码的依赖项。

此问题有许多有效的用例。 如果要创建一个纱线维护者,他们会愿意接受PR吗?

如果您仍与该项目有联系,请ping @kittens ...

同时,我在package.jsonscripts部分中使用以下脚本:

"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.jsonyarn add XXXX --no-lockfile至少可以解决本地开发和测试的问题。
添加最终会出现(预期的)权限错误,但是添加的模块之后会出现在node_modules中,并且我可以使用本地安装的对等依赖项进行测试,但不能将其持久化在package.json中,而是作为对等依赖项。

有时我会临时需要调试库,例如why-is-node-running 。 我知道我会在单次使用后摆脱它,并且--no-save选项将允许我安装并忘记,而不会冒污染我的依赖项的风险。

我正在使用Lerna,我真的只想在发布阶段的CI步骤之一中安装_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}来撤消所做的修改,然后才能推送标签。

我没有试图修改源。 我不想,这也不关我的事,这取决于我组织中的开发团队。 对于某些抽象哲学,您使我的生活更加艰难。 停下来。

任何想法,为什么这个问题已经解决? PR中是否已添加--no-save开关?

有时我想更改从依赖项引入的模块版本。 例如,另一个开发依赖项带来的@types/sinon最近破坏了我的tsc。 我不想将@types/sinon赋予我的开发依赖项,但我想使用yarn add @types/[email protected] --no-save手动更改版本,以便我可以继续工作。 相反,我只是切换回npm。 超级令人沮丧。

我有一个仅用于生产的依赖项(应用程序动力学),这本身就是特定于平台的二进制文件的hack。 事实证明,开发机器上甚至不需要它。 添加yarn add ... --no-save可以使我们整洁地部署,而脚本不会危及package.json(特别是因为package.json令人讨厌地不能使用注释来解释每个脚本或依赖项的目的)

cc @小猫@hpurmann

请解决这个令人难以置信的热门问题,或者将其锁定为已解决。 对于以上提出的所有批评,有一个具体的答案将是高度赞赏的。

社区已准备好提供此功能,请让我们知道您是否愿意接受这样的请求。 谢谢。

哈哈,仍未实施,niiiiice

你为什么想要这样的事情存在?

人们对JSX最初混合模板和逻辑时说的一模一样。 如果可能并且有用例,正确的问题应该是为什么不呢? 我的意思是这是一个标志,它不是默认行为,因此您在明确地告诉纱线(又名我知道我在做什么)。

@小猫@hpurmann
我有多个基于react的软件包,这些软件包彼此之间具有子模块依赖性。 因此,我有一个peer-dep来使用react和react-dom,但是当我需要分别构建这些软件包时,我确实需要react和react-dom。
我猜这将是在本地安装软件包而不将其添加为dep的合适用例。
我不希望npm在我的项目中有这么微不足道的用途。
任何更新,等待类似于--no-save
我想如果社区需要,添加一个功能并没有什么害处,假设开发人员已经意识到它的副作用(在运行yarn install时就松开本地软件包)。
谢谢

方便的把戏是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之后是相同的。
更不用说如果您要以编程方式执行该操作,那么绝对不能创建目录,链接等。

一些案例

例如? 当然很奇怪吗?

@hpurmann @小猫

那么,开发具有对等依赖关系的程序包的推荐做法是什么?

如果我的包中有React作为peerDependency,是否也应该将它添加为devDependency以解决导入问题?

https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json我猜答案是肯定的

在某些情况下可以使用此功能。

就像在CI生命周期中一样,我添加了一些报道记者。 但是我不能将它们带到package.json然后影响发布NPM

保存还是不保存,我认为这个选择应该取决于开发人员而不是工具。

好吧,让我们尝试从维护者的角度来看这件事。 我绝对可以看到天真的--no-save解决方案的弊端。 我们在这里没有得到非常详尽的解释,但是我将尝试构造一个钢铁侠。 也许他们可以纠正我。 也许我们可以找到一个折衷方案。 @小猫@hpurmann

(对不起,这比我预期的要长。)

现代节点和Web应用程序的依赖管理有些混乱。 但是,我们需要一个能够为我们提供可靠的自动化以及一定水平的控制和可预测性的系统,并具有重复数据删除和可复制的构建等功能。

为了处理复杂性,我们需要知道安装了什么以及为什么安装,而且我们需要一个单一的事实来源来解决任何不一致之处。 冒着明显的风险, node_modules本身不能履行这些角色。 遍历速度太慢,传递速度太大,对版本控制的粒度太细,并且无法对“为什么”方面进行编码。 这就是为什么我们有package.jsonyarn.lock

通过为我们提供通过接口的受限访问,Yarn封装了node_modules的复杂性。 如果我们承诺不破坏封装,我们将获得一定的保证,例如重复数据删除和可复制的构建。 如果我们在node_modules安装东西而未在package.jsonyarn.lock进行相应更改,则我们将失去这些保证。

而且,这是许多开发人员没有明确意识到的潜规则。 当他们破坏它时,他们不是故意地这样做。 因此,当出现问题时,可能会被不公平地归咎于纱线。 另外,制作很难用脚踩死自己的工具并不是一个坏的设计理念。

但是,我可以看到几个折衷的原因:

  • 这里似乎确实有需要。 只要看一下上面注释中列出的许多用例,以及“竖起大拇指” /“竖起大拇指”的比率。 面对如此单方面的回应,维护者明显的固执并不能使Yarn看起来太好。

  • 有一些可能适用于每个人的解决方案。 例如,引入一个新文件yarn.local.lock 。 开发人员会将其放在.gitignore ,并且它将保留所有带有--no-save标志安装的软件包及其依赖项的记录。

    为了使yarn.lock与此隔离,限制了“本地”依赖项树的重复数据删除和扁平化。 本地锁定文件可以适应以匹配主锁定文件中的版本(在这种情况下为重复数据删除),但不能相反。 结果,许多可传递的本地依赖关系可能不会变平为node_modules

    使用此解决方案,Yarn可以继续跟踪所有软件包,开发人员可以在不污染其回购的情况下安装东西,并且我们保留可复制的内部版本。 (还有package.local.jsondevDependencies部分的空间,但我不确定是否需要。)

  • 人们已经在使用变通办法来获得他们想要的东西,上面的评论中至少描述了其中三个。 但是它们使用起来不方便,不能提供相同的保证,并且要求开发人员与Yarn进行斗争以解决它们。 这是两全其美。

我可能错过了一些东西,但这似乎是值得进行的对话。

我还有另一个用例:我希望REPL中提供一个模块,但不想在我的代码中使用它。 就目前而言,我需要进入另一个文件夹并在其中安装该模块,然后使用../other-project/data/xyz.json导入一些json文件。

但是,如果我想导入一个模块,而那件事使用相对路径导入其他模块,那将会中断。

只是让我在不保存的情况下将模块安装到node_modules会使事情变得容易得多。

我很惊讶维护者对这个想法的抵制。

天哪,我只是阅读了之前的评论,维护者的态度令人失望。 我开发了许多特定于框架的插件,这些插件依赖于框架库,并且我想避免将这些作为硬依赖性添加到我的插件中。

我有一个依赖于peerDependencies定义的特定软件包的插件,现在像许多其他人已经评论的那样,问题是,如何在本地安装依赖项而不将其添加到package.json文件? 好吧,你不能。

我发现的唯一解决方案是将peerDepenciesdevDependencies ,这虽然一点都不理想,但是可以解决该问题。 至少npm处于可怕状态,无需修改package.json文件。

@hpurmann @小猫

您是否已放弃对社区的回应? 显然,忽略此问题并没有给您带来任何好处,也没有消失。 如果您甚至不回答某个人是否完成工作并提交PR的简单问题,将其称为开源项目有什么意义?您会接受吗?

@viveleroi解释了他相当有效的用例(你们中很多人似乎都知道过)之后,我大概应该早就回答了。 当时我竖起了他的回答,显然还不足以引起注意。

我改变主意了。 通常,人们想要很多东西,如果维护者接受每个功能,该软件就会变得肿。 我没有这个用例,但我看到很多人都想要它。

我什么也不能决定。 我不是这个项目的维护者。

@Vheissu yarn add --peer <dep>什么问题?

对我来说,添加--peer直到您添加了另一个软件包,该软件包才能工作,这时将从本地安装中删除现有对等部门,您必须手动读取它们。

我想要此功能,因为今天是因为我正在使用express编写我的库的示例实现,但是我的代码都没有直接依赖于express。 我不想安装任何东西或不依赖Express,但是我想将其安装到当前目录中。

就像@ brendan-hurley @suyanhanx一样,我有一些要安装在CI中而不是本地的依赖项。
我希望将本地依赖性保持在最低水平,这样我们就不必浪费node_modules并为每个从事此项目的开发人员花费时间和空间。

CI中需要但本地不需要的软件包:

  • CI专用工具:语义释放,greenkeeper-lockfile
  • 覆盖率报告工具:编码覆盖率,工作服
  • CI的测试报告工具:jest-junit等。

这就是我们需要此功能的原因:

使用yarn link不会链接软件包的依赖项,因此您需要将它们安装在
链接的目标-将这些外部依赖项添加到package.json只会带来很多不便。

yarn link必须添加依赖项或提供一种排除目标package.json

我有一个非常深奥的用例,但这对我会有所帮助。 我完全理解为什么yarn.lockpackage.json作为真理的源头很重要,并且如果我使用--no-save命令,我的更改将在随后的yarn上消失

就是说,我希望yarn相信我知道我在做什么,并允许我传递--no-save标志。 如果遇到任何问题案例,我都会确切地知道出了什么问题,而且我只能怪自己。 :微笑:

我的用例?
我运行一台64位Win机器。
产品机器是32位的。

除非我们更新程序包,否则我们仅支持32位节点对节点的依赖。

不更改package.json或yarn.lock中的依赖关系以支持开发机。
因此想在本地安装最新的node-sass以支持64位,但不影响package.json和yarn.lock

我想将@types/*软件包安装到非TypeScript项目中,而不会污染package.json / yarn.lock以便在VSCode中实现更好的自动完成。

我在纱线工作区使用lerna。
Antd的类型定义由于@ types / [email protected]更新而中断。
Antd将在周末解决此问题。
但是现在我需要强制纱线在不影响当前package.json的情况下,将@ types / [email protected]的固定版本手动

保持默认的保存到package.json的行为是正确的,但是在实际情况下,开发人员必须安装该模块而不影响package.json。 特别是当某些程序包中发生一些意外的重大更改时。

隐式更新包并隐式保存到package.json会导致冲突。

这是另一个用例。 我维护一个React库。 在发布新版本之前,我想对reactreact-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 )失败。

我想在我的CI管道中添加其他软件包以进行测试,而无需触摸package.json文件(可能是只读文件挂载)。
这些不是开发组件的一部分。
在开发机器上进行开发和测试期间,不得安装它们,在构建和生产期间不得安装它们,它们仅在测试期间在CI服务器上是必需且可接受的。

这仅通过使用npm即可起作用,但是yarn应该能够消除npm时的依赖性。
这很可能会使我们回到仅使用npm而不是仅使用yarn的情况。

同样,这也违反了纱线能够完全替代npm的承诺,因为它根本无法完成npm所能做的事情。

同样,是的,绝对将此功能隐藏在某些标志的后面,因为这不是正常的用例,而是边缘用例。

你在开玩笑吗 ? 3年添加一个简单的开关?

另一个用例:我们使用npm包( git-hoooks )进行预提交检查。 并非团队中的每个人都安装了节点,因此在package.json中包含它会破坏某些人的提交。 因此,我正在尝试创建npm脚本,以通过安装/删除git-hooks来临时启用/禁用钩子。 非常失望地发现用纱线几乎不可能完成这个看似简单的任务。

如果担心的是yarn.lock将不再是node_modules内容的真实来源,那么,这有什么不好呢? 现有功能不能简单地忽略未跟踪依赖项的存在吗? Yarn是一个很棒的工具,维护者为JS社区提供了很棒的服务,但是他们需要重新考虑这个决定。

你在开玩笑吗 ? 3年添加一个简单的开关?

@spanasik@Ryuurock :在讨论免费提供给您的高质量软件时,请保持礼貌。

之所以用了不到三年的时间,是因为切换起来实施起来太复杂了–因为维护者仍然不相信这对用户是一个净收益。 如果您不同意此功能,请为该功能进行论证。

@NickHeiner这里是10个参数的屏幕。 导致挫败感的主要原因不是维护者不服气,而是当人们“不同意这一点,对该功能进行论证”时,他们会忽略维护者,不要回覆争论。 当人们感到沮丧时,他们当然会留下不愉快的评论。 请不要将整个事情归咎于用户。

我同意,如果维护人员在这里讨论这个问题会更好。 几年来,广泛的人们显然对此产生了兴趣。 因此,也许我关于@spanasik@Ryuurock应该只是“争论”的建议是不合理的,因为它可能像这里的其他所有内容一样被忽略。

当人们感到沮丧时,他们当然会留下不愉快的评论。 请不要将整个事情归咎于用户。

我不同意。 这种无礼仍然不是向前迈出的有益一步,也不是成年人可接受的行为。 不礼貌是证明维护者进一步忽略这一点的一种好方法:“线程只是巨魔”。

建设性的前进方式:

  1. 在其他渠道(也许他们忽略了它)上引起维护者对这个线程的注意,并要求他们至少承认这里的论点,即使他们不同意。
  2. 分叉/替换纱线并以人们更满意的方式管理项目。

方便的把戏是yarn add --dev pkg && yarn remove pkg 。 它做同样的事情。 锁定文件保持不变,因此保持不变。

经过测试-不起作用。

我的用例如下:
一些软件包具有可选的加载项,并通过“ require”加载。 我不想将这些加载项添加到devDependencies部分中,因此我要进行“纱线添加我的加载项”并将其手动从package.json文件中删除。 在我的云CI管道上,我使用'npm i'添加它们(用于测试)。 在我的本地管道上,我不想使用npm,因为它会创建一个额外的锁定文件。 我现在最好的选择是使用npm,然后删除其锁定文件(以删除出现的第二个事实版本)。

因此,在阅读完所有内容后,我对维护者的疑问是:

  • 你为什么这么矛盾?
  • 为什么不通过所有功能正确实施这一理念?

    • 也就是说:决定应如何为我们所有人完成事情,并从所有功能中删除所有其他选项。 坚持到底! 保持自己的本性!

不可否认的是,所有好的软件都有配置设置,因为好的软件将允许用户选择最适合自己情况的软件。 始终触摸'package.json'文件是一种很好的做法-但由于这种理念,在某些极端情况下'纱线'不能胜任这项工作。

我真的很喜欢毛线,因为它既简单又快速。 不幸的是,维护者们正在打一场他们肯定会放松的战斗-因为社区被迫退回到缓慢可靠的npm以使事情正常进行。

让我们稍微降低温度。 没有人需要被一个厌恶
允许他们免费使用的软件。

2020年1月15日,星期三,23:17 Hajime Yamasaki Vukelic <
[email protected]>写道:

我对纱线使我无法以某种方式工作感到恶心。 我喜欢
我自己决定事情,当我的工具告诉我如何做时,我不喜欢这样
应该工作,因为我的智力是问题中最少的,并且
迄今为止,最大的事情是无法完成工作。

相信完美的规则,永远不会有机会
打破他们是天真的。 “最佳做法”与
“做死”。 正如奥利弗·温德尔·福尔摩斯(Oliver Wendell Holmes Sr.)所说:

年轻人知道规则,但是老人知道例外。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件,在GitHub上查看
https://github.com/yarnpkg/yarn/issues/1743?
或退订
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA

做自己的包管理器,没人能做任何事情。

一点也不生气,只是指出您的逻辑错误:

纱线使我以某种方式工作。

Yarn并没有使您做任何事情,他们制造了一个工具(免费),并且以某种方式起作用。 如果您不喜欢它,请使用其他工具。

@foxbunny非常感谢您澄清您的厌恶情绪。 :)

即使您认为这是合理的,并且只是在这种情况下感到恶心,我也不认为语言是与为您构建了此免费工具的人们交谈的一种礼貌方式。 您可以在保持尊重的同时给出建设性反馈。

@whitecolor团队有一个要点。 该选项--save很愚蠢。 node_modules,package.json和锁定文件之间的纱线保证平衡,这很棒。 这样比较安全.... npm --save很危险。 让我失望了很多次

请你停下来

或者每个人都只是使用以他们认为更好的方式工作并冷静下来的工具。

我的用例是

我想更新我们的应用程序的从属关系
我将此依赖项与yarn link
然后在我们的应用程序中使用链接的
我在我们的库中添加了一些依赖
yarn install (wtf no.1)之后没有在主应用程序中安装添加的lib依赖项
然后我想,好吧,让我们快速地添加它而不保存到应用程序中,这样我就可以在发布更新到我们的库之前检查某些东西是否有效
但是-不。

谢谢

很抱歉看到社区被作者忽略了。

作为一名开源志愿者,需要有一个连贯的理念或
项目将退化为泥泞的球。 这意味着有时候
人们“不”。 如果您不同意,欢迎制作自己的包裹
经理,就像用纱代替了npm。

2020年3月3日,星期二,03:53 Artur Kwiatkowski [email protected]
写道:

很抱歉看到社区被作者忽略了。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件,在GitHub上查看
https://github.com/yarnpkg/darn/issues/1743?
或退订
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA

我正在使用Lerna,我真的只想在发布阶段的CI步骤之一中安装_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

不知道是否曾经讨论过这个用例。 让我尝试解释一下我的情况-我在一个仓库中有一堆相互依赖的软件包。 它们都使用相同的外部依赖项,并在下面的根服务子项目中使用通用软件包,每个本地软件包都需要按顺序构建以供下一个使用。 我正在尝试为此使用纱线工作区。 首先,我在根package.json中没有定义任何本地包。 在构建完所有组件的一个完整周期之后,我最终得到了一个具有这些本地依赖项的完全更新的root package.json。 现在,当此更新的更新程序基于CI构建时,所有添加的本地程序包将由于不可用而失败。 我们必须删除那些新添加的条目以使其在CI中起作用。

我必须先yarn install xxx然后yarn remove xxx

相同

这是一个希望能够做到这一点的用例:

我们正在构建一个带有模块化生态系统的工具,用于在工具中“家用电器”,并且计划是使用这些设备设置本地实例,并通过配置动态激活它们。 这些设备已发布到npm(如果需要,可以在我们的框架之外调用)。

vanilla项目不依赖于这些软件包,因此保存到package.json将是不合适的。 特定实例的配置可能要求其中一个软件包在本地安装。

尽管我们将继续探索替代方法,但缺少此功能似乎是我们项目的局限性决定。

在我阅读“维护者”答复之前,我以为我是有史以来最顽固的人。

近四年...🤦

“固执”与“具有设计远见,没有实现任何人所要求的一切”不同。

“固执”与“具有设计远见,没有实现任何人所要求的一切”不同。

设计愿景描述了一条快乐的道路,而逃生舱口正是这里所要求的,这为更广泛的社区增加了实用性。

为什么不只在锁定文件中添加一个节来跟踪“自由格式”安装以及现状的增量快照(在node_modules ),以使它们安全可逆? 或者也许将依赖项放在与node_modules分开的文件夹中,并使用node_modules只是为了使链接保持暴露于其程序包,因此Yarn实际上可以自行管理内容,而不必担心看不见的安装会覆盖和破坏内容。

Git在您之前解决了这个问题,赶上了! 只是想出一些东西! 这就是设计-绕过限制,而不是与之抗争(或屈服于它们)。

两端的隧道视力是由于无知,过度思考和不必要的极化而产生的。 没有武术,哲学,革命或政治。 只有一个工具,一堆代码和一份工作要做。 如果该工具不能帮助您完成工作,则它不是针对特定情况的工具。 对于像Yarn这样的自称通用替代品的工具,这里忽略了许多常见情况,只是在挖自己的坟墓。

当我们可以绕过它时,我觉得每个人都在互相推挤,爬上狭窄的山丘。

此页面是否有帮助?
0 / 5 - 0 等级