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

Question

(Create-React-App)当在子文件夹中运行react-scripts build(c:\Repos\web_app1\api_ui)及其自己的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.4web_app1 ，因为它取决于babel-loader v7.1.4
• 删除 c:\Repos\web_app1 中的 node_modules 不是一个选项。这是父应用程序，需要自己的node_modules.
• 我的修复方法是添加SKIP_PREFLIGHT_CHECK=true到 .env 文件。这看起来像是一个黑客行为，我想要另一个涉及通过预检检查进行构建的修复。
• 子文件夹中的 package-lock.json(c:\Repos\web_app1\api_ui)具有正确的babel-loader 版本 (8.0.4)，那么为什么它会转到父文件夹呢？

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

Answer 1

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

|-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-loaderin react-scriptsget the babel-loaderin 本身node_modules，即 version 吗8.1.0？我可以删除node_modules任意package-lock.json次数，但问题似乎始终存在。

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

• 包裹吊装
• 传递依赖

包裹吊装

我不会详细说明包提升何时发生，但它确实发生了。基本上，它相当于将B依赖项的依赖项包A添加到项目根node_modules（或其他某个父级node_modules）而不是添加到node_modulesof A。

所以而不是

|-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通常，每当我们有冲突的包版本时，就会使用“朴素策略”，即“包的所有依赖项都在其自己的包中”。这就是上面的例子中发生的情况，有两个不同版本的babel-loader; storybook实际上由多个包组成，其中多个包使用babel-loaderversion ^8.0.0。当storybook安装 before时react-scripts，它​​会采用满足约束的最新版本babel-loader，并将其提升到顶级node_modules。react-scripts这会在安装时导致常见的问题。我有另一个具有相同设置的项目，但react-scripts之前安装在哪里storybook。在那里，babel-loader版本被提升，并且由于该包也满足( )8.1.0的要求，因此不再需要更多的。在这里，不抱怨。当然，最好能够自行计算出这个顺序，从存储角度来看这也是最佳的（只有一个而不是两个），但据我所知，在处理依赖项时使用字母顺序。storybook^8.0.0babel-loadercreate-react-scriptsnpmbabel-loadernpm

传递依赖

尽管包A是我的项目的依赖项，但A也可以有自己的依赖项。这些是关于我的项目的传递依赖项。

为什么不起作用？

react-script在version的源代码中4.0.3，该文件verifyPackageTree负责运行检查帽结果，导致问题中出现无聊的错误消息。该文件在以后的预发行版中不再存在，但在顶部，我们找到了注释：

// 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包，则该包不会驻留在下面，而是驻留在 root 中，其中（相对于最上面的示例）也驻留在版本（与到 )文件夹中的版本。现在，如果要导入，则会出现错误，例如不是预期的版本，而是相反。在线程中，这被认为是一个错误，尽管我不完全知道为什么它会是一个错误。也许，可能会有一些标志指示是否可以吊起一个包裹，因为如果完全吊起被认为是一个错误，那么看起来就像是倒退。Xnode_modulesreact-scriptsnode_modulesbabel-loader8.2.68.1.0node_modulesreact-scriptsXbabel-loaderbabel-loader8.1.08.2.6npm

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