Yarn: 添加一种方法来安装软件包对等方依赖项以进行开发/测试

创建于 2016-10-27  ·  72评论  ·  资料来源: yarnpkg/yarn

您要请求_feature_还是报告_bug_?
特征

目前的行为是什么?
不适用

预期的行为是什么?
提供一个CLI命令yarn install --peer ,它将安装package.json指定的对等依赖项。 这样开发/测试可以使用对等对象,例如react / ng2 / grunt。

cat-feature help wanted triaged

最有用的评论

+1这对于图书馆作者很重要

所有72条评论

@ jpollard-cs我不是指将软件包添加为对等依赖项,而是指有一种方法来安装当前列为对等依赖项的所有软件包。
否则,没有可行的方法来开发插件。

npm install
将安装在package.json依赖项部分中声明的所有包。

yarn add --peer
我希望这将安装package.json peerDependencies部分中声明的所有软件包。

有没有一种方法可以在peerDependencies中安装已声明的软件包?

我的用例是开发/测试react native模块。

这是NPM问题,他们已将其关闭: https :

对于NPM开发者来说显然不重要。

+1这对于图书馆作者很重要

我已经在NPM问题上写过这篇文章,但是对于纱线人来说:

我写了一个cli程序来安装包的对等依赖项:

# If you're using npm
npm install -g install-peerdeps

# If you're using yarn
yarn global add install-peerdeps

cd my-project-directory

install-peerdeps <package>[@<version>]

# for example
install-peerdeps @angular/core
# will install all of angular's peerdeps

如果您有任何问题,请在仓库中打开一个问题!

@nathanhleung ,该软件包似乎安装了所有依赖项对等项依赖项。 这张票到底是关于什么的。 这是关于安装您自己的程序包的对等依赖项。

我已经用一个软件包修复了它,以做到这一点https://www.npmjs.com/package/@team-griffin/install -self-peers

@nathanhleung,你很

嗯...如果一个人需要开发/测试依赖项,难道不应该把它们放在devDependencies吗? 不试图投下炸弹或任何东西...

@nikolakanacki完全了解您的来源,我认为很奇怪,因为它既是对等依赖又是开发依赖,因为您永远不要强迫消费者安装您的开发依赖。 我投票决定可以轻松安装同行!

@nikolakanacki如果您创作的软件包依赖于用户安装的另一个软件包,则您不希望在devDependencies中使用它,这可能会导致该软件包在不同版本中出现重复。在某些情况下,这是没有意义的...

用例eslint查找规则

程序包查找未在配置中配置的ESLint中可用的规则。
为了使它对用户有意义,它需要检查他们安装的ESLint软件包,而不是软件包附带的某些特定版本(或latest )。
因此,这是一个peer依赖性。

现在,如果您想为该项目做出贡献,则希望在node_modules中安装ESLint,以便可以测试代码,而无需对安装ESLint的虚拟项目做一些npm-link。

当用户运行yarn ,系统不应安装对等部门并警告他们丢失(此方法有效)。

因此...如果一个标志可以使纱线安装同等的dep(如果尚未安装)将很好地解决该问题。

有趣的一点

  • yarn add <package> --peer将其安装到node_modules并将其添加到package.json
  • yarn add <other_package>之后从node_modules中删除已安装的软件包

我目前正在使用@nikolakanacki模型,它似乎可以正常工作。 我同意这可能会造成混淆,我希望yarn install --peer安装dependenciesdevDependenciespeerDependencies但这对我同样有效。

如果我正确使用@kyleholzinger / @gaastonsr ,则不希望在开发模式下安装peerDependenciescd -ed到具有peerDependencies的仓库/软件包中

需要说明的是:您安装了eslint-find-rules ,它抱怨您需要eslint作为依赖项(这是peerDependencyeslint-find-rules ),所以现在您想要一种简单的方法将那些依赖项添加peer您正在处理的eslint-find-rules )? 诸如“解析并添加为新的依赖项(修改package.jsonyarn.lock )与当前依赖项最匹配的对等项依赖项”之类的东西?

如果这是您的观点,那可能会非常有用,我认为您指的是在开发时自动安装它们。

引入此功能可能会带来更多的纯粹便利,例如:多个依赖项可能依赖于对等目标中的同一程序包,但需要使用不同的版本-此功能可以通过尝试解决一个最佳问题来充分利用此功能。 -匹配目标(如果可能)。

绝对要考虑的事情。

如果这是您的观点,那可能会非常有用,我认为您指的是在开发时自动安装它们。

这就是我要的东西。 开发软件包时安装peerDependencies。

是的,正是@nikolakanacki! 我觉得我们有很大的机会可以帮助人们管理同伴的部门。

@gaastonsr需要将其添加到devDependencies然后-就是这么简单。 您的软件包已损坏,无法开发。 克隆项目并运行yarn -应该安装所有内容,并且应该能够运行测试等。

在这种情况下,在安装上述依赖项之前,应该问两个简单且完全不相关的问题:

  1. 我的程序包依赖于此程序包,但是我希望目标项目包含它,因为我的程序包只是该程序包的插件:将其放在peerDependencies
  2. 我有依赖于此程序包的测试,但是出于某种原因它未在我的dependencies中列出(并且不应在此处列出):将其放入devDependencies

换句话说:所有预期在开发过程中存在且未作为正在开发的软件包的直接依赖项列出的软件包都应位于devDependencies 。 重复不是问题-在文档中没有任何地方说明在这些情况下不允许/鼓励重复。

@nikolakanacki当我们为软件包构建插件时,应取决于用户安装的软件包版本,如果将其添加为devDependency ,则不可避免地将安装其他版本,并且将使用该版本代替用户的版本。

除非我们将依赖项定义为* ,否则Yarn应该具有确定性,并且应该使用用户安装的软件包而不是我们的软件包。

目前情况并非如此:

@alexilyaev我认为@nikolakanacki意味着同时将其安装为peerDependency和devDependency。

这有一个问题,我们需要保持两者同步。 对我来说,它现在很有效,但我认为它并不理想。

@alexilyaev声明peerDependency ,还要声明其版本。 除非目标项目安装的对等依赖性的版本也满足您定义的版本,否则yarn / npm将报告错误(缺少对等依赖性)。

非$$$ devDependency与它无关,它是在源包中运行yarnnpm install安装的一个(声明对等项的依赖项,例如:一个插件),并且在第三方程序包/项目(对等方)正在使用该程序包时,甚至不进行咨询。

关键是:我不知道这一切有什么关系?

我可以看到使它们保持同步的痛苦,但是您可以轻松地编写一个bash / javascript / <whatever>脚本,该脚本会在package.json

我要说明的一点是,我们绝不应该破坏devDependencies情绪,或者更糟的是引入“运行yarnnpm install不一定安装所有此程序包的必需依赖项”概念。

另一方面, yarn引入了更严格的策略,它清除了没有定义为dependenciesdevDependencies的软件包,因此您不会运行稍后再讨论。

@nikolakanacki假设我的插件接受^7.0.0 ,而最新的对等节点是7.9.0 ,并且用户在其package.json 7.4.0
如果我在devDependencies中也有^7.0.0 ,那么(针对用户)Yarn不会同时安装7.9.07.4.0吗?

如果是这样,我的插件可能会误用已安装的7.9.0而不是7.4.0

@alexilyaev与其他任何其他程序包一样,您的程序包将始终使用满足该对等dep的程序包中定义的“ semver range”的最高可用版本。

我会更具体一些,但我不太理解您提出的情况,请您澄清一下吗?

〜它将警告您您有peerDependency不兼容,您的插件期望^7.0.0并且您具有版本7.4.0 。〜更新: ^7.0.0满足7.4.0

Yarn不会同时为用户安装7.9.0和7.4.0吗?

纱线不安装peerDependencies你并不会安装devDependencies在你的插件只是依赖dependencies

@gaastonsr你是绝对正确的,只是^7.0.0由满足7.4.0

如果软件包不是主软件包,则默认情况下不会安装对等依赖项,默认情况下不会安装dev依赖项。 “最终用户”需要通过将它们添加到项目的常规“依赖项”以及范围,来定义希望满足的对等依赖项。 它可以满足或不满足您在插件中所需的“ semver range”,并且将向用户通知后者。

npm解释的Semver范围: https ://docs.npmjs.com/misc/semver
如有疑问,请始终检查: http :

@nikolakanacki能够轻松地安装对等依赖性软件包会很棒!

@nikolakanacki好的,因此,当最终用户安装软件包时,不会安装devDependencies ,因此软件包作者也应将peerDependenciesdevDependencies

因此,这解决了本地发展问题。

但是,似乎很多项目都没有将对等项依赖项添加为dev依赖项。
所以我想我们应该开始传播这个词,并开始进行项目。
这将不可避免地引起长时间的讨论,讨论为什么它要与npm一起使用而不与Yarn一起使用,并且不管结果如何,都将花费一些时间,并且并非所有项目都可以进行更改。

所以...我提议仍然支持一种安装对等依赖项的方法,至少这样我们就不必再使用install-peerdeps了。

这里的实际问题是什么? 似乎安装一个deps列表不会比安装另一个deps列表更复杂。 对等依赖已经存在了几年。 这怎么不打扰任何人?

@nikolakanacki解决方案非常devDependencies进行隔离测试(在提供所需peerDependencies的宿主项目之外),并且需要peerDependencies进行集成测试并确保主机项目不会以冗余/重复的软件包安装结束,因为它使用的库使用相同的dependencies不是_正确使用peerDependenciesdevDependencies

让他们保持同步有点头疼。 但是正如@nikolakanacki指出的那样,可以通过一些post-install脚本轻松地缓解这种情况。

有什么解决办法?

我已经足够快地浏览了评论,却没有注意到一个简单的解决方案:

如果始终在顶级软件包中,请始终将peerDependencies安装为常规依赖项

它非常适合开发/测试用例,并且不影响软件包的依赖关系安装。 类似于yarn.lock的逻辑。 不需要额外的“开发”或任何模式。

实际上,由于与peerDependencies相关的其他毛线错误,在某些情况下它的行为也似乎完全正确。

非常同意,如果您在仓库中运行“ yarn install”,它将安装deps中未列出的所有对等依赖项。 在这方面,我真的没有看到它与开发依赖项有什么不同—如果您在该模块上进行开发,则需要安装这些模块

由于我无法清楚了解问题所在以及所提出的解决方案(如果存在),因此我将结束本次讨论。

随时进行澄清或提出新的错误重新打开。

@BYK您真的确定自己做对

我认为这非常简单:在顶级package中进行设置时,请确保安装了peerDependencies
或者说另一种方式:在当前程序包中设置peerDependencies作为常规依赖项

如该线程中进一步建议的那样,将对等依赖项也添加为开发依赖项,将破坏流类型: https :

@andvgal我只是想整理问题,数月前这里的所有讨论都非常

我认为这非常简单:在顶级软件包中进行设置时,请确保安装了peerDependencies。
或者说另一种方式:在当前程序包中设置peerDependencies作为常规依赖项

这是一个很棒的总结,谢谢。 重新讨论这个问题,但是如果我们决定采用这种方式,那么我们需要非常仔细地考虑默认情况下安装peerDependencies的含义。

或者-至少-提供一种无需触摸package.json文件即可单独安装对等依赖项的方法。 使用add安装对等项依赖项时,将修改JSON文件中的条目。 如果您以不同于默认的yarn编写方式来设置semver表达式,则会对其进行更改。

我认为添加--peer开关进行安装的想法很好,但是我实际上希望能够一个一个地安装它们,因为我经常链接其中一些模块,并且我在链接和实际之间来回切换已安装模块。 有了npm,我就可以运行'。 在Yarn中,我看不到等效项。 具体来说,我希望能够使用package.json中的规范安装一个文件,而无需修改package.json文件。

@jimsugg ,我一直在使用yarn add <package...> -p来手动安装已经在package.json中列出的对等依赖项,这绝对是一种反模式。 似乎应该在开发环境中自动安装对等依赖项(如果实际上是对等依赖项,那么至少应该进行要求该软件包的测试)。

我一直在寻找相同的东西,并提出了此Bash一线安装所有列出的对等部门(要求您安装jq): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json)

我希望这可以帮助其他人。

@EdwardDrapkin谢谢你,传奇的想法! 我扩展了它并最终添加了一个npm脚本来执行此操作:

"install:peers": "yarn add -P $(jq -r '.peerDependencies | to_entries | map(\"\\(.key)@\\(.value | tostring)\") | join(\" \")' package.json)",

只需维护peerDependencies的版本规格即可;)如果您不想使用latest标签,而是在其他类似的地方工作,例如next ,则只能在这里进行。

@shousper这是一种没有jq依赖性的方法:

node -e "const peers = Object.entries(require('./package.json').peerDependencies || {}).map(d => d.join('@')).join(' '); if (peers.length) process.stdout.write('yarn add -P --no-lockfile ' + String(peers));" | sh

是否有一种情况,当您直接在Foo上工作时,不想安装软件包Foo的对等依赖项? 我想不到一个。 如果要求Bar使用Foo ,则在处理Foo时需要它,并且由于它是对等依赖项,因此不能成为常规依赖项。 然后,仅当直接在软件包上工作时才必须安装它,这是dev依赖项所做的。

因此,我认为对yarn来说,将peerDependencies与devDependencies一样对待是有意义的,但是随后也要执行它们现在所做的事情,即生成警告。 我通常只是将每个对等依赖项都设为devdependency,因此可以节省一些重复。

是否有这样做的理由? 这可能是一个重大更改,因此必须等到2.0,但除此之外,似乎还不错。

一个问题可能是您需要为开发人员安装比同行要求更特定的版本。 在这种情况下,我想说,您应该能够通过在devDependencies中复制对等版本来进行本地安装。 例如

peerDepdency:[email protected]^16.0.0
devDependency:[email protected]~16.1.0

将本地安装的React限制为〜16.1.0,但允许任何v16版本作为对等依赖项。 我不确定在什么地方需要这样的东西,但这似乎不是无效的。

我同意@bdwain ,我从语义上理解对等和dev依赖之间的区别是什么,但实际上它们的安装方式完全相同。 如果您正在开发模块,则需要同时安装dev和peer依赖项;如果您使用的是模块,则只需安装其列出的实际依赖项。 如果真是这样,我看不出没有很好的理由在install命令中不具有dev和peer依赖项

@bdwain @kyleholzinger我不同意,因为peerDependencies严格来说是为了通知需要依赖的,而不是指示安装依赖的实际操作。

这样可以确保不会无声地(并且错误地)使用根/顶层软件包中也存在的瞬态依赖版本问题。 以babel-core为例。

在纱线的上下文这里的缺乏支持是定义为两个对等体和DEV DEP,的能力如这里所述

就是说,为了与对等部门的默认安装规范保持一致并提供更好的开发者体验....也许yarn可以为install命令引入--include-peers选项?

@hulkish虽然我同意这种观点,但是当您想将某些内容声明为对等依赖项,而将_not_声明为dev依赖项时,将是一个示例吗?

如果我正确理解了用法,尤其是对yarn,则对等依赖项列表始终是dev依赖项的子集。 如果是这样,那么我认为这应该得到正式认可,并且您无需将对等依赖项声明为dev依赖项。

我提出这个问题的唯一原因是,我认为添加一个命令/选项会同时增加一些东西,因为开发者和对等者都觉得这会增加一般的yarn的复杂性,而且我觉得这里有一个解决方案很不错简单simple

@kyleholzinger

@hulkish虽然我同意这种观点,但是当您想将某些东西声明为对等依赖关系而不是声明为dev依赖关系时,将是一个示例?

当不需要它来运行单元测试或.build时。 根据我的经验,实际上,这是唯一需要在两个地方都添加它们的方法。

我认为这里的解决方案是让yarn引入允许自动安装对等项的选项。 请注意,使用peerDependencies的主要好处是可以了解何时使用了不兼容的瞬时依赖项。 这里的关键是不破坏安装时对等deps的默认行为。

我认为@hulkish在谈论一种情况,其中您依赖于依赖项的依赖项来引入对等依赖项之一。 但是,我认为这不会引起任何问题,因为传递依赖项仍需要匹配对等依赖项所指定的范围,无论如何,该范围必须很大。 如果传递依赖关系比对等依赖关系更具体,则该范围将具有优先级,并且仍将满足所有要求。

@废话

当不需要它来运行单元测试或.build时

完全明白了! 尽管这引出了一个问题:如果某项是对等依赖项,但您不需要将其用于单元测试或构建运行,那么为什么要将它作为对等依赖项呢?


保持亲切感,使用peerDependencies的主要好处是可以了解何时使用了不兼容的瞬时依赖项

我非常同意这一观点,我认为对等依赖现在对于模块的使用者来说是惊人的,它宣布对具有对等依赖的库的依赖,我的主要抱怨/痛点是在具有对等依赖的模块上进行开发。 对不起,有什么困惑!

我主要的询问/建议/希望获得批准才能进行工作是,当您在自己的package.json中具有对等依赖性的模块中yarn install (不在生产​​中)时package.json它的开发依赖项以及对等依赖项都已安装。 这是关键的区别,目前仅安装了dev依赖项,因此您必须将deps声明为dev依赖项和对等依赖项。


@bdwain @笨蛋

我认为@hulkish在谈论一种情况,其中您依赖于一个依赖项的依赖项来引入一个对等依赖项

我是专门在谈论在开发具有对等依赖项的模块时执行yarn install时间,而不是在将具有对等依赖项的模块添加到另一个项目时

@bdwain不完全是,要描述绝对是一件易事。 我将尝试使用一个示例:

有问题的用例

假设这是您的顶级套餐:

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

然后,您的foo / package.json:

  "dependencies": {
    "react": "^16.0.0"
  }

根据此依赖关系树,当您运行yarn / npm install时,您的node_modules目录将如下所示:

node_modules/
  react/ <-- @^15.0.0
  foo/node_modules/react/ <-- @^16.0.0

在这一点上,除非您(出于某种原因)决定自愿检查您的node_modules嵌套目录结构-您永远不会知道有问题。 这不是软件包管理器的错-它可以准确地完成其工作。

因此,peerDependencies旨在通过将它们视为更多的验证检查而非安装说明来解决此用例。

peerDependencies解决方案的用例

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

然后,您的foo / package.json:

  "peetDependencies": {
    "react": "^16.0.0"
  }

首先,让我们清楚一点,这两个用例都存在相同的问题,即反应版本彼此不兼容。

该用例的区别在于: 代替了这个问题,默默地存在。 当您运行npm / yarn install时,程序包管理器有责任将不兼容性报告为错误或警告。

希望这能更好地解释它。

@kyleholzinger

我是专门在谈论在开发具有对等依赖关系的模块时何时安装纱线,而不是在将具有对等依赖关系的模块添加到另一个项目时

我明白。 我认为对等部门的默认行为应保持原样。 但是,我认为一个简单的解决方案是允许通过cli和/或env vars和/或.yarnrc 。 像--install-peers-as-dev

@废话

但是,我认为一个简单的解决方案是允许通过cli和/或env vars和/或.yarnrc对其进行配置。 像--install-peers-as-dev这样的东西

当然好! 我个人认为它们不应该同时属于开发依赖和对等依赖,但这可能是一个单独的讨论。 我认为添加此选项将是一个可靠的折衷方案,同时也是解决问题的一种好方法-我将检查一下并尝试将它们放在一起:)

@kyleholzinger这是一个开始的好地方https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

另外,我建议您在公关中转发将peerDependencies作为dev安装时,您要确保仍然报告任何兼容性警告或错误。

@hulkish我了解什么是对等依赖项。 我的观点是,在实践中,您始终需要出于开发目的而安装它们,因此,除了它们在版本不匹配时发出警告的作用之外,还应将它们视为devDependencies。

如果软件包Foo对Bar具有对等依赖关系,则直接在Foo上工作时不希望安装Bar的唯一情况是构建和自动测试不需要Bar。 但是,如果是这种情况,那仅意味着您的构建/测试没有行使首先需要对等方依赖Bar的功能,这不应该是常见的情况。

我真的不认为启用对等依赖项自动安装的选项是正确的选择,因为它经常会被使用(除非您也将对等体指定为dev依赖项,这会破坏观点)。 如果经常需要某个选项,则该选项应为默认选项,并且应有一个选项将其禁用。 yarn install应该在大多数情况下都没有选项,并且需要将对等方依赖项视为dev依赖项是最常见的情况。 为普通用户增加额外的步骤只会带来更糟糕的体验。

将它们自动添加到开发人员和对等方仍然存在在两个地方复制依赖项的问题,这是IMO的问题,因此不必要。

无论哪种方式,都需要报告这些警告/错误。

我们怎么可能还没有此功能? 我不熟悉创建npm软件包,但它似乎是开发npm软件包的核心工作流程的一部分。

一样@biels! 我实际上完全忘记了我说过我将要对此进行处理,所以还没有开始,我会尽力尝试进行处理,以便我们至少可以让人们将这个选项放在.yarnrc然后不必一直担心

我认为此功能非常重要。

我可以想到许多用例,尤其是在涉及库作者时。

假设我想开发一个具有reactreact-dom作为peerDependencies的组件库(我不希望它们最终被使用它的人捆绑在一起,这会重复这两个库,可能会引起问题,这是我以前遇到的)。

我想在安装了peerDependencies下测试我的组件库,所以我想在CI和我的机器上运行yarn --include-peerDeps (或类似的东西),但是当有人运行yarn在他们自己的程序包上,我希望他们使用自己的reactreact-dom依赖性来运行他们的测试(不管他们如何做)。

我还认为,由于我们已经有了可以做到这一点的模块,并且下载量很大,因此已经有理由将该功能设为本机。 (“使人们想要的东西”这一古老的座右铭适用于IMO)

我看不到这可能是一个不好的做法,因为必须通过--include-peerDeps对其进行显式切换。

如果需要,我很乐意讨论并提供实施帮助。

@lucasfcosta完全同意! 这些天,我没有太多时间来处理它,因此一直在尽量尝试,但似乎无法从命令行选项获得选项的真实性。 会很乐于助人的:)

@lucasfcosta这是我认为该选项可能存在的地方

我目前正在使用复制方法(devDependencies和peerDependencies),但是非常喜欢此功能,所以我可以停止这样做。

我也需要在此期间,我已经完成了一点节点任务

const pkg = require('./package.json');
const entries = Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
for ([dep, version] of entries) {
    deps[deps.length] = `${dep}@${version}`;
}

deps.push('--peer');
const cmd = deps.join(' ');
console.log('Installing peer deps!\n -----', cmd);
const result = shell.exec(cmd);

if (result.code !== 0) {
    shell.echo('Error: installing peer dependencies');
    shell.exit(1);
}

凉! 现在我们可以将其粘贴到纱线中并添加一个标记或其他内容。

2018年10月4日,星期四,17:29 Pasquale Mangialavori [email protected]
写道:

我也需要在此期间,我已经完成了一点节点任务

`const pkg = require('./ package.json');
const条目= Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
用于(条目的[dep,version]){
deps [deps.length] = $ {dep} @ $ {version};
}

deps.push('-peer');
const cmd = deps.join('');
console.log('正在安装对等deps!n -----',cmd);
const结果= shell.exec(cmd);

如果(结果代码!== 0){
shell.echo('错误:安装对等依赖项');
shell.exit(1);
}`

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件,在GitHub上查看
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046或静音
线程
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo

我也采用@RWOverdijk所说的重复方法。 希望将来能看到此功能。

顺便说一句,有没有人有更好的解决方案,这样我们就不需要重复添加一个软件包(devDependencies和peerDependencies)了?

你好,将来。 对于包/ lib开发人员来说,这仍然是一个问题。 重复的部门不应该是答案。

我肯定希望看到此功能。 如果不将react到程序包的devDependencies ,则无法对代码运行测试。

在本地peerDependencies对象中安装软件包的标记会很好,但我也看不到将_only_ local peerDependencies为默认行为的不利之处。 从语义上讲,这是有意义的,需要同级依赖项才能使程序包在其他任何地方都可以工作,为什么本地会有任何不同?

我对标志的用法有以下看法,因为它与
yarn add --peer命令。

yarn --peer
# and
yarn install --peer

至少应引入标志。

我想知道在这里使用单独的test应用程序是否是一个好的解决方案? 然后,您可以添加所有peerDependenciesdependencies的的test应用程序。 这似乎执行以下操作:

  • peerDependencies保留在您库中的devDependencies
  • 您将以某种方式e2e测试您的库...确保dist正确构建,您正确导出了所有组件以及类似的东西
  • 避免在使用本地依赖项(如"my-package": "file:/path/to/my-package"时从包中清除node_modules时偶尔出现的Invalid hook call错误

如果有更多信息对人们有帮助,我创建了一个示例存储库,以对这种方法进行建模并记录问题:
https://github.com/jamstooks/package-peer-dependencies

现在,您应该能够运行npx install-peerdeps <package> ,然后CLI会询问您是否要使用Yarn进行安装,如果文件夹中有纱线锁等。 至少刚才对我有用。

在此NPM RFC中,这里有来自Arcanis(“在缺少的对等dep上失败安装”)和Isaac(“自动安装对等dep失败”)的更多讨论:

https://github.com/npm/rfcs/pull/43

这篇博客文章帮助我解决了这个问题: https :

我有一个相关的问题。
对于最低限度的复制,我具有以下依赖项列表:

  "dependencies": {
    "prismic-reactjs": "^1.2.0"
  },
  "peerDependencies": {
    "react": "^16.12.0"
  },
  "devDependencies": {
    "react": "^16.12.0",
    "redux": "^4.0.5"
  }

说明:我的程序包在运行时依赖react存在,并且也需要它进行测试。 redux用于演示,请参见下文。

现在, prismic-reactjs也依赖于react作为其对等依赖项。
调用yarn --production之后会发生什么?

React是_installed_和_hoisted_
我希望这两个都不会发生。

出于演示目的,在此处添加了redux ,这是_not_安装的(我认为)证明了临时对等方依赖性是问题的原因。

复制仓库: https : 运行test.sh进行快速检查。

npm v7现在具有此功能...为什么不将其添加到yarn中?

@sajadghawami据我所知,@arcanis大约有这样一些相当大的保留意见:

https://github.com/npm/rfcs/pull/43#issuecomment -520584797

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

相关问题

ewingrj picture ewingrj  ·  3评论

torifat picture torifat  ·  3评论

wagenet picture wagenet  ·  4评论

selkhateeb picture selkhateeb  ·  3评论

celicoo picture celicoo  ·  4评论