在子位置运行时，react-scripts 父文件夹 node_modules 错误

Question

当在子文件夹(c:\\Repos\\web_app1\\api_ui)运行 react-scripts build (Create-React-App)和它自己的package.json 、 node_modules文件夹等时，我收到以下错误：

 react-scripts build


There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "babel-loader": "8.0.4"

Don't try to install it manually: your package manager does it automatically.
However, a different version of babel-loader was detected higher up in the tree:

  c:\Repos\web_app1\node_modules\babel-loader (version: 7.1.4)

• 将父文件夹的(c:\\Repos\\web_app1) babel-loader 更新到 v8.0.4不是一个选项，因为web_app1取决于babel-loader v7.1.4
• 删除 c:\\Repos\\web_app1 中的 node_modules 不是一个选项。 这是父应用程序，需要自己的node_modules 。
• 我的修复是将SKIP_PREFLIGHT_CHECK=true添加到 .env 文件。 这似乎是一个黑客行为，我想要另一个涉及通过预检检查构建的修复程序。
• 子文件夹(c:\\Repos\\web_app1\\api_ui)的 package-lock.json 具有正确的babel-loader 版本 (8.0.4) ，那么为什么它会转到父文件夹？

在子文件夹中构建反应脚本时，有没有办法忽略父文件夹或更高的树节点node_modules ？

Answer 1

这也让我很困惑，我做了一些研究，查看了react-scripts版本4.0.3的源代码。 这个版本需要babel-loader v. 8.1.0 。 安装storybook （需要版本^8.0.0 ），我们在顶级node_modules获得了不同的babel-loader ，因此我们最终得到：

|-src
|-node_modules
  |
  |-storybook 6.3.12
  |-babel-loader 8.2.6
  |-react-scripts 4.0.3
    |
    |-node_modules
      |
      |-babel-loader 8.1.0

我得到同样的错误消息，很多人都看到了，我心里想着，不应该使用任何的babel-loader在react-scripts让babel-loader在自己node_modules ，即版本8.1.0 ？ 我可以删除node_modules和package-lock.json任意次，但问题似乎始终存在。

你如何描述它的问题，实际上是在包管理器（至少是如何npm ）的作品，如进口babel-loader从react-scripts会给它的版本8.1.0从自己node_modules ......但我们忘记了两件事情，结合起来会导致问题：

• 包裹吊装
• 传递依赖

包裹吊装

我不会详细介绍包提升何时发生，但它会发生。 基本上，它相当于将依赖项A的依赖项包B添加到项目根node_modules （或其他一些父node_modules ）而不是添加到A的node_modules中。

所以代替

|-src
|-node_modules
  |
  |-A
    |
    |-node_modules
      |
      |-B

......我们得到......

|-src
|-node_modules
  |
  |-A
    |
    |-node_modules (might exist anyway)
  |-B

由于npm工作方式（正如您在问题中正确理解的那样），如果B在node_modules/A/node_modules ，它将在node_modules查找包，这使得这项工作有效。 当许多包都需要兼容的依赖项时，提升可以是一种优化，这样我们就可以只存储一个，而不是存储 N 个相似版本的依赖项。 它还简化了项目根节点node_modules的文件夹结构，从而更易于调试。 事实上，默认情况下是提升任何可以提升的包，例如，在要提升到的node_modules不存在的node_modules 。

通常，只要我们有冲突的包版本，就会使用“在其自己的node_modules对包的所有依赖项”的朴素策略的回退。 这就是上面例子中使用两个不同版本的babel-loader ； storybook实际上由几个包组成，其中多个包使用babel-loader版本^8.0.0 。 当storybook在react-scripts之前安装时，它采用最新版本的babel-loader满足约束，并将其提升到顶级node_modules 。 当安装react-scripts时，这会导致熟悉的问题。 我有另一个具有相同设置的项目，但是在storybook之前安装了react-scripts 。 在那里， babel-loader版本8.1.0被提升，并且由于这个包也满足storybook ( ^8.0.0 ) 的要求，不再需要babel-loader 。 在这里， create-react-scripts不会抱怨。 当然希望npm可以自己计算出这个顺序，这从存储的角度来看也是最优的（只有一个babel-loader而不是两个），但据我所知， npm在处理依赖项时使用字母顺序。

传递依赖

即使包A是我的项目的依赖项， A也可以拥有自己的依赖项。 这些是与我的项目相关的传递依赖项。

为什么不起作用？

在react-script版本4.0.3的源代码中，文件verifyPackageTree负责运行 check hat 导致问题中无聊的错误消息。 这个文件在以后的预发布中不再存在，但在它的顶部，我们找到了评论：

// We assume that having wrong versions of these
// in the tree will likely break your setup. 
// This is a relatively low-effort way to find common issues.

往下几行写着：

// These are packages most likely to break in practice.
// See https://github.com/facebook/create-react-app/issues/1795 for reasons why.
// I have not included Babel here because plugins typically don't import Babel (so it's not affected).

查看引用的线程，有一个关于为什么在安装不兼容的依赖项时create-react-app中断的讨论与上述相同的问题......为什么它不起作用？

最后的结论似乎是，例如，如果react-scripts导入了一个已经被提升的包X ，这个包不会驻留在react-scripts下的node_modules ，而是驻留在根node_modules ，其中（相对于最上面的例子）也babel-loader版本8.2.6驻留（相对于版本8.1.0在node_modules文件夹的react-scripts ）。 现在，如果X要导入babel-loader ，它会得到错误的babel-loader ，例如不是预期的版本8.1.0而是8.2.6 。 在线程中，这被认为是npm一个错误，尽管我不完全知道为什么它会是一个错误。 也许，可能会有一些标志表明是否可以提升包裹，因为如果完全提升被认为是一个错误，它似乎是倒退。

因为create-react-app的编写者无法知道某些依赖项是否被提升，所以他们实现了这个简单的检查，它会抛出一个警告。 对于高级用户，他们有机会使用SKIP_PREFLIGHT_CHECK标志选择退出检查。 另外，最好记住错误来自create-react-app ，而不是npm ，所以它真的没有说明npm是如何工作的，只说明了create-react-app的create-react-app者认为的问题（这是最初确实同样令人困惑）。