@chinesedfan你试过yarn upgrade-interactive吗？

@milesj是的，结果相同，我还更新了问题描述中的重现步骤。

那是因为yarn add [email protected] 1.0.0 。

yarn upgrade尊重您的 package.json semver 范围，并且由于您准确指定了版本 1.0.0，因此它不会提供升级到其他版本。

您可以通过以下几种方式解决此问题：

• yarn upgrade --latest将忽略 semver 范围并查看注册表中标记为latest的内容。
• 更改 package.json 以接受^1.0.0之类的版本范围，然后是yarn upgrade （您可能必须先yarn install才能让它更新更改范围的锁定文件）
• 明确指定upgrade的版本，例如yarn upgrade [email protected]或yarn upgrade is-alphanumerical@^1.0.0

编辑：

抱歉，我刚刚注意到有不同的包名称。 alphanumerical和alphabetical乍一看是一样的 :)

是的，由于is-alphanumerical没有升级，因此不会更深入地遍历依赖关系树来处理其传递依赖关系。

您可以尝试添加--force标志，看看这是否使其成为子依赖项。 否则我认为你是对的，除了yarn remove is-alphanumerical和yarn add is-alphanumerical之外，没有简单的方法可以做到这一点

@rally25rs感谢您的回复！ 我又测试了2个案例。

• yarn upgrade is-alphabetical --force也不起作用。
• yarn upgrade is-alphanumerical将升级其所有子依赖项，即使它已经是最新的。
  
  
  
  • 但是如果我只是想升级一个指定的子依赖，那还是不太方便。
  
  

是的，这是目前纱线的一个主要问题。 并且已经在 #2394 讨论

重复 #2394

请重新打开：它不是重复的。

2394 描述了meck-test-bb包的复制（间接依赖）：

我有两份 meck-test-bb

这个问题只描述了升级间接依赖的能力（不知何故）。

@rally25rs 请原谅我 ping。

@rally25rs ，拜托，你已经关闭了两个非重复问题，这是错误的。 请给我们升级间接依赖的能力！

抱歉，在其他问题上有些混乱。 我最初认为 2394 是在寻求一种使用--deep标志或类似标志来升级传递 dep 的方法，因此我将此问题标记为该问题的副本。 后来在重新阅读 2394 之后，我认为它是关于一些不同的东西，这不是我最初想的那样的重复。

对此功能请求 +1。 对于像我这样需要在此期间手动升级特定间接依赖项的愚蠢的人来说也是一个示例：

鉴于显式依赖jsonwebtoken已将隐式依赖jws^3.0.0解析为易受攻击的jws=3.1.4 ：并且您需要将其解析为已修补的3.1.5 ：

从 yarn.lock 中删除jws条目，例如下面的条目，然后重新运行yarn 。 间接依赖和任何受影响的包都将被更新，而不涉及其他东西（至少在 yarn v1.3 上）

jws@^3.0.0, jws@^3.1.4:
  version "3.1.4"
  resolved "https://registry.npmjs.org/jws/-/jws-3.1.4.tgz#f9e8b9338e8a847277d6444b1464f61880e050a2"
  dependencies:
    base64url "^2.0.0"
    jwa "^1.1.4"
    safe-buffer "^5.0.1"

编辑：标点符号

@alex-thewsey-ibm，感谢您的解决方法！

在纱线 v1.7 上工作。

ty，工作纱线 1.9.2

可能有助于以选择性依赖resolutions轻推纱线，即使它是针对单个依赖项。 感谢@remolueoend的提示！
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

从文档：

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": {
    "left-pad": "1.0.0",
    "c": "file:../c-1",
    "d2": "file:../d2-1"
  },
  "resolutions": {
    "d2/left-pad": "1.1.1",
    "c/**/left-pad": "1.1.2"
  }
}

我们需要 Autoprefixer 中的这个功能来建议用户如何在他们的yarn.lock https://github.com/postcss/autoprefixer/issues/1184中更新caniuse-lite

这里同样的问题。 我预计yarn upgrade caniuse-lite browserslist会升级子依赖项。 它没有这样做，也没有给我一条错误消息，说它无法升级它 b/c 它不是依赖项。

删除相关的锁定文件条目，然后按照@alex-thewsey-ibm 的建议重新运行yarn为我解决了当前的问题。

对我来说很奇怪纱线缺少 tnis 功能。 我是纱线（和 npm）的新手，所以假设必须有办法做到这一点。 我仍然不完全确定是否有一种不明显的方法可以做到这一点，而这个线程中没有人知道，或者是否真的没有办法做到这一点。

如果真的没有办法在不将其添加到 package.json 的情况下升级 lockfile 中的传递/间接依赖项......我不明白 yarn 用户如何没有它。

这是 IMO 的意外行为 - 我最近尝试使用yarn upgrade [email protected]更新 lodash，但它仍然没有针对任何临时依赖进行更新。

我仍然剩下所有指向旧版本的major (^4.XX) 和patch (~4.17.X) 版本。

修复它的唯一方法是通过手动编辑yarn.lock然后运行yarn upgrade来合并更改。 我希望这种广泛使用的工具会更好一些。

默认情况下，这是公认的错误还是纱线是保守的，我应该手动编辑yarn.lock或使用一些标志？

我怀疑我有与@Machiaweliczny相同的安全警报要解决；）在我们等待项目修复自己的项目时覆盖间接依赖关系非常有用。 即使有高度响应的项目​​，等待修复和发布也会有延迟。

实际上，这对于间接依赖中的安全问题是有问题的，并且编辑yarn.lock的解决方法虽然有效，但令人失望且难以自动化。 如果由于某种原因这不是默认行为，最好添加一个像--include-indirect这样的选项，它会强制 Yarn 遵循间接依赖关系。

我不认为它应该需要一个选项，我不明白为什么yarn upgrade [an indirect dependency]不只是将 yarn.lock 更新为依赖树允许的间接依赖的最新版本，而不需要其他选项。 我认为现在这只是一个无操作？

但是，我发现我很满意的另一个解决方法是将resolutions添加到我的 package.json 中。 如果lodash是间接依赖项，并且我知道我需要它 >= 4.7.13 以避免安全漏洞，我可以添加到我的 package.json 中：

  "resolutions": {
    "lodash": ">= 4.17.13"
  }

然后只需运行yarn install ，它将更新yarn.lock以满足该要求，或者如果它不能满足该要求，则抱怨它与间接依赖项冲突。

在我的情况下，这实际上似乎效果很好。 我想知道这是否不是“解决方法”而是预期的解决方案？ 我花了一段时间才发现。 而且我对事情的理解还不够好，无法确定这是一个通用/正确的解决方案，或者在某些情况下是否可能存在任何问题。 如果它是升级间接依赖的“正确”解决方案，那就有点难找了。

为什么不安装您要更新的传递 dep 但不提交 package.json 更改，只提交 yarn.lock？

为什么不安装您要更新的传递 dep 但不提交 package.json 更改，只提交 yarn.lock？

我认为这不会（总是？）起作用，因为 yarn 会很乐意安装同一个包的多个版本，即使一个版本可以满足所有相关的 semver 范围。 因此，这将安装您想要的版本，但不会删除您不想要的版本。

@djmitche对。 您需要在预期范围内安装版本。 不理想且有点乏味，但目前是可用的权宜之计。

@djmitche确实，这对于间接依赖项中的安全问题是有问题的，并且编辑yarn.lock的解决方法虽然有效，但令人失望且难以自动化。

这是另一种更自动化的解决方法：

yarn remove is-alphanumerical
yarn add is-alphanumerical

使用 PR 描述中的示例，这将删除顶级 dep 然后重新添加它，这将根据is-alphanumerical指定的范围（例如插入符号范围）获取其所有最新的子dep . 然后它将生成一个新的锁定文件。

副作用是它会更新所有不理想的子部门。 对于 sub-dep A 中的安全问题，我只想更新 sub-dep A。

将 sub-dep A 添加为直接 dep 以解决安全问题的解决方法更糟糕，因为它会造成混乱（不直接使用包）以及维护负担。

纱线去除是字母数字
纱线添加是字母数字

这似乎是实际更新依赖项的唯一可靠方法。 我今天意识到我们被困在一个1.0.0版本的软件包上，该软件包在一年前更新为1.1.0 。 我们使用的包确实使用^1.0.0并且我们一直“升级”那个包它从来没有选择新的1.1.0版本的依赖。
事实证明，我们的产品中有一个非常糟糕的错误，它本应在一年前修复，而无需我浪费一天时间调查我们为什么会遇到这个问题。

我无法相信手动编辑 yarn.lock、删除然后重新添加包或使用选择性分辨率是更新间接依赖项的“方法”。

IMO， yarn upgrade应该将间接依赖项更新到最新接受的 semver 版本，这就是我们升级包的原因。 我的意思是，如果 semver 范围内出现中断，它将更新间接依赖项，因此它应该始终这样做。

编写某种外部脚本来执行此操作会有所帮助吗？ 我想它只会删除给定包的所有yarn.lock条目，然后重新运行纱线？

有一个简单的脚本可以做到这一点： https ://gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

可以请一位维护者将标签从cat-feature更改为cat-bug吗？

可以请一位维护者将标签从 cat-feature 更改为 cat-bug 吗？

为什么？ 这不是错误。 这是设计的。 yarn upgrade从未打算用于升级传递依赖项。 最初打开的“问题”甚至被标记为功能请求。

在内部upgrade使用yarn outdated来确定什么是过时的以及要升级到什么版本。 outdated仅检查直接依赖项。

我可能是错的，或者它已经改变了，但我很确定至少在 3 年前yarn upgrade最后一次返工时，$# npm upgrade 4$#$ 也没有提供一种方法升级一个可传递的 dep。 （同样，多年来这可能已经改变了，我对 npm 的变化并不太了解）。

任何人都可以自由提交 PR 以添加此功能。 这是一个开源项目，由整个社区做出贡献。 此功能请求已开放多年，但没有人加紧实施它，这就是它没有被“修复”的原因。

@nnmrts你能检查我的脚本https://github.com/yarnpkg/yarn/issues/4986#issuecomment -562719589 它现在对你有帮助吗？

@rally25rs对不起，我又累又脾气暴躁，认为我的评论已解决。 😬

@nnmrts你能检查我的脚本#4986（评论）现在对你有帮助吗？

不幸的是，那个脚本对我不起作用，昨天试了一下。 也许我做错了什么，但我的整个 yarn.lock 文件被脚本“清空”了。

我不确定这种解决方法有多好，但我运行了我写的这个脚本：

const fs = require('fs')
const lockfile = require('@yarnpkg/lockfile')
const package = require('./package.json')

const lock = lockfile.parse(fs.readFileSync('yarn.lock', 'utf-8')).object

const allDeps = new Set()

const parseDep = ([name, version]) => {
  allDeps.add(`${name}@${version}`)
}

Object.entries(package.dependencies).forEach(parseDep)
Object.entries(package.devDependencies).forEach(parseDep)

const newLock = Object.fromEntries(Object.entries(lock).filter(([dep]) => allDeps.has(dep)))
const newLockString = lockfile.stringify(newLock)

fs.writeFileSync('yarn.lock', newLockString)

然后运行yarn install ，它似乎安装了最新版本的间接依赖项。

我能够成功解决深层/间接依赖关系。 我想知道我们什么时候会得到官方的支持。

https://medium.com/@ayushya/upgrading -javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

我已经尝试解决并解释了重新生成 yarn.lock 的风险，并提出了应该怎么做的建议。

让我知道这是否也适合你们。 或任何改进升级过程的建议。

@ayushya嗯，这似乎确实有效，天才。

我想知道 yarn 是否会接受一个补丁，其中yarn upgrade到间接依赖（或其他命令？）只是......这样做了吗？

@jrochkind我本来期望yarn upgrade的间接依赖项来升级它，即使它不是我的直接依赖项。 如果没有该功能，您可能会落后于间接依赖项的更新数年。

就我而言，我试图升级fsevents ，以便在我执行yarn install时不会出现错误（https://github.com/fsevents/fsevents/issues/278 ）。 fsevents不是我直接使用的包——它是webpack-dev-server使用的东西。 但令人震惊的是，当webpack-dev-server首次安装在这个应用程序中时，我被锁定到任何存在的版本。

我不得不使用这个技巧来升级它，这似乎是一个彻头彻尾的黑客攻击。 https://github.com/yarnpkg/yarn/issues/4986#issuecomment -395036563

解决方法对我不起作用，不幸的是，旧的深度依赖项在删除后再次添加到 yarn.lock 文件中。 运行 yarn install 后，我可以在 node_modules 文件夹和 yarn.lock 文件中看到它们。

也许解决方法与纱线工作区不兼容？

@FelipeLujan当解决方法有效时，深度依赖项仍会再次添加到 yarn.lock 文件中——这是预期的——但有新的更高版本。 但只有在发布了新版本并且依赖树允许它们的情况下才使用新版本。 如果某些中间依赖项表示不允许升级的限制，它们仍然无法升级。 它们只是升级到树中限制允许的最新版本。

我不使用纱线工作区，所以不能说这是否相关。

@FelipeLujan AFAIK 纱线工作区以类似的方式工作。

删除包部分的解决方法只会将包升级到最新的MINOR/PATCH版本。
如果要将包升级到更新的MAJOR版本，则必须找到运行yarn why package-name-here的包依赖链并在其链的顶部升级包。

注意：请测试您的代码，因为将软件包升级到更新的主要版本可能会带来一些重大变化。

https://github.com/djmitche/yarn-minify可能对此有所帮助..

@ayushya的解决方法对我来说非常有用，手动编辑 yarn.lock 以删除间接依赖项，然后运行 ​​yarn install 以在以后的版本中重新添加它。

对我来说，这似乎是一个应该内置到 yarn 中的功能，而不是要求您手动编辑 yarn.lock。 制作一个好像您手动编辑以删除依赖项并运行 yarn install 的功能似乎应该是相当简单的。 我觉得这个功能真的应该内置到纱线中，我有点困惑为什么它不是。

我能够成功解决深层/间接依赖关系。 我想知道我们什么时候会得到官方的支持。

https://medium.com/@ayushya/upgrading -javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

我已经尝试解决并解释了重新生成 yarn.lock 的风险，并提出了应该怎么做的建议。

让我知道这是否也适合你们。 或任何改进升级过程的建议。

我认为这与@alex-thewsey-ibm 给出的解决方案相同。 从 yarn.lock 中删除特定的依赖对我有帮助。
无论如何，感谢这个黑客☺️

在package.json中使用resolutions对我有用https://github.com/webpack/webpack-dev-server/issues/2739#issuecomment -695164486

这至少应该返回一些警告：

yarn add [email protected]
yarn upgrade is-alphabetical

这就是我得到的：

success Saved lockfile.
success Saved 0 new dependencies.

package.json和yarn.lock的变化为零，即使有新的is-alphabetical软件包版本可用。