Gatsby: [fsevents错误]卡在MacOS上的“源和转换节点” /“ createPagesStatefully”

已更新-我测试了注释掉gatsby-node.js文件的情况，并且构建一次进行了，但是随后我再次尝试并执行此操作，它再次卡在同一位置。

这是否有可能是由于我的计算机较旧，2010 Macbook Pro（升级到8GB Ram和SSD）尚未阻止我，但我知道它的日子很有限。 这对我来说是一种业余爱好，我有小孩，因此没有钱花在新计算机上，因为这台计算机与升级的Ram和SSD配合使用效果很好。

我试图恢复到gatsby 2.13.52，这是我稳定的最后一个版本，我还尝试恢复对16.8.6的反应。

有趣的是，当我恢复对16.8.6的响应时，有一次我成功构建了它，但是在那之后第一次它挂在了同一位置，这对我来说确实是奇怪的行为。

我也很少能无缘无故地辨认出它的性能。 似乎没有韵律或原因。 我花了几个小时寻找可能导致这种情况的模式或错误，但没有找到任何东西。 我查看了https://github.com/gatsbyjs/gatsby/issues/6654，并尝试了其中的一些项目，但无济于事。

这是我所遇到过的最奇怪的错误之一，因为行为似乎在没有代码可识别的更改的情况下就改变了。 在某些情况下，该构建挂在源节点和转换节点上（占时间的60％），在某些情况下，它挂在“有状态地创建页面”（占20％）上，在某些情况下，它在构建上成功（占20％）。 我已经在不更改代码的情况下显示了所有这三种行为。

我也在gatsby-starter-blog中复制了此行为，这确实很奇怪。 再次让我觉得这是我本地的问题。 有趣的是，它只挂在createPagesStatefully 。

我现在开始认为它与由自制程序自动更新的库有关-我不知道该库是什么，但这是我能想到的唯一未测试的库。

这是到目前为止我尝试过的事情的列表：

• 更改节点版本，尝试使用12、10和8

• 恢复到我的提交历史记录中有效的上一个点-现在仍然失败。

• 注释掉gatsby-config的插件和区域

• 注释掉我的gatsby-node.js的内容

• 在仍然成功构建的Netlify上再次进行测试，这使我认为它必须与计算机有关。

• 删除src / pages目录中的4个页面，并放入一个非常基本的index.mdx文件

• 删除所有的node_module和lock文件，然后重新安装

• 重启电脑

• 使用Github的主题/启动器的新克隆创建新鲜的纱线工作区。

• 测试gatsby-starter-blog，行为类似，但挂在createPagesStatefully

你好，

我无能为力，但可以肯定的是，我在许多gatsby初学者上都看到了这个问题。 而且，正如您所指出的，它有时只是决定构建或停止构建，挂在“源和转换节点”或createPagesStatefully。

非常令人沮丧，并导致尝试进行最残酷的尝试来修复它。

我没有看到这个问题，但这听起来很尴尬，我真的很想知道您这一行为的原因。

制备
您应该尝试使用节点调试器来找到问题的根源。 package.json中的任务将如下所示。 如果您使用的是VSCode，则可以启用“自动附加”功能以与该任务一起使用内部调试器（请确保为此目的使用内部终端）

"start:debug": "node --inspect=127.0.0.1:9232 node_modules/.bin/gatsby develop",

当然，只要确保正确连接调试器，调试就可以在任何IDE上进行。

1.变体：极少繁殖
您已经提到createPagesStatefully作为问题的根源。 如果您确定这是问题的根源，则可以创建一个很小的项目来重现它。 抛弃所有启动程序，直接使用gatsby并使用createPagesStatefully到gatsby-node.js并使用一些示例来模仿您的启动程序正在做的事情。 然后启动gatsby并通过节点检查对其进行调试。

这样，您可能会发现它的挂起位置。

2.替代方法：在您的项目/启动器内部
您当然可以尝试使用相同的技术调试项目内部的问题。 但是也许您有多个正在堆积的问题，并且使您对问题原因的看法变得模糊。 因此，在调试之前，我总是会尽量减少复制量。

祝好运。

所以...我在使用锁定文件时遇到了一些奇怪的行为。 也许知道更多的人可以指出我正确的方向。 在尝试达到最小工作量的过程中，我基本上简化为安装“盖茨比”的“ hello world”，但仍然无法正常工作，真是奇怪。

更奇怪的是，实际的gatsby-starter-hello-world确实可以正常运行并且在我的计算机上可以正常运行。 但是...如果我删除了锁定文件并让yarn重建了新的锁定文件，则构建会开始失败，挂在源节点和转换节点上。 如果我从“ hello-world”复制了锁定文件并使用了该文件，则可以精简代码并减少构建的实现。 因此，我目前的理论是，锁定文件中存在某种版本问题，这会导致此问题，但我一直被困在这里。

我还删除了我所有的自制软件安装，并重新安装了node，yarn，git等。只是为了确保它不是那种有趣的事情。

感谢@ehowey提出这个问题。...我以为是我自己，因为它是断断续续的（但发生的时间超过50％）。 尝试和调试情况相同。 当我挂在⠙ source and transform nodes ，通常意味着必须杀死我的终端机。

如果我发现一些问题，我会通知您。 我也会看这个线程。

@georgiee-感谢您提供--inspect信息。 我将看看是否可以使用WebStorm进行节点调试。

我也喜欢您关于最小复制的想法。 但这需要时间，而我才能更深入地了解盖茨比。

目前，它挂在“源和转换节点”上。 很少，它可以完全创建createPagesState并挂在那里。 否则，它将正常构建。

在执行“纱线升级”以修复易受攻击的依赖关系后，我目前也面临相同的问题。 这是我的设置：

系统：
作业系统：macOS 10.15
CPU：（4）x64 Intel（R）Core（TM）i7-7567U CPU @ 3.50GHz
外壳：5.7.1-/ bin / zsh
二进制文件：
节点：12.8.1-/ usr / local / bin / node
纱线：1.17.3-/ usr / local / bin / yarn
npm：6.10.3-/ usr / local / bin / npm
语言：
Python：2.7.16-/ usr / local / bin / python
浏览器：
铬：76.0.3809.132
的Firefox：68.0.2
Safari：13.0
npmPackages：
盖茨比：^ 2.13.42 => 2.14.7
盖茨比背景图像：^ 0.8.3 => 0.8.6
盖茨比影像：^ 2.2.7 => 2.2.15
gatsby-plugin-manifest：^ 2.2.4 => 2.2.10
gatsby-plugin-netlify：^ 2.1.4 => 2.1.10
gatsby-plugin-netlify-cms：^ 4.1.6 => 4.1.12
gatsby-plugin-offline：^ 2.2.5 => 2.2.10
gatsby-plugin-react-helmet：^ 3.1.2 => 3.1.5
gatsby-plugin-react-svg：^ 2.1.1 => 2.1.2
gatsby-plugin-sass：^ 2.1.3 => 2.1.12
gatsby-plugin-sharp：^ 2.2.9 => 2.2.18
gatsby-plugin-typography：^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts：^ 1.1.0 => 1.1.0
gatsby-remark-images：^ 3.1.10 => 3.1.19
gatsby-remark-relative-images-v2：^ 0.1.5 => 0.1.5
gatsby备注响应式iframe：^ 2.2.5 => 2.2.10
gatsby源文件系统：^ 2.1.6 => 2.1.18
gatsby-transformer-remark：^ 2.6.12 => 2.6.19
gatsby-transformer-sharp：^ 2.2.5 => 2.2.12

在执行“纱线升级”以修复易受攻击的依赖关系后，我目前也面临相同的问题。 这是我的设置：

更新：我设法通过恢复旧的“ yarn.lock”文件来解决问题。

@ hbthen3rd

更新：我设法通过恢复旧的“ yarn.lock”文件来解决问题。

我的经验是，该问题可以毫无明确的理由消失，只能稍后再返回。 尽管恢复yarn.lock，您仍可能会发现返回问题。 保持联系。

这是使用gatsby-starter-hello-world的最小复制品：

https://github.com/ehowey/gatsby-test-lockfiles

存储库中包含的当前锁定文件对我来说是失败的。 我还在yarn-working.lock和yarn-notworking.lock的回购中包含了副本。 希望这可以使某人更容易进行故障排除。

我当前的环境：

系统：
操作系统：macOS High Sierra 10.13.6
CPU：（2）x64 Intel（R）Core（TM）2 Duo CPU P8600 @ 2.40GHz
外壳：3.2.57-/ bin / bash
二进制文件：
节点：10.16.3-/ usr / local / bin / node
纱线：1.17.3-/ usr / local / bin / yarn
npm：6.10.3-/ usr / local / bin / npm
语言：
的Python：2.7.10-/ usr / bin / python
浏览器：
铬：76.0.3809.132
的Firefox：67.0.2
Safari：12.1.2
npmPackages：
盖茨比：^ 2.13.73 => 2.15.0
npmGlobalPackages：
gatsby-cli：2.7.40

我遇到了同样的问题。

我发现了一些方向：

1. 将gatsby-plugin-sitemap从2.2.9降级gatsby-plugin-sitemap 2.2.6可解决yarn develop 。

   • 这很奇怪，因为gatsby-plugin-sitemap不会影响开发构建。

2. yarn build仍然不起作用，但是当我从配置中删除gatsby-plugin-sitemap ， yarn build再次起作用。

@sharvit我可以报告这在我的情况下不起作用。 很高兴为您修复了该问题，我认为它最终与锁定文件有关，并且在锁定文件的深处存在一些奇怪的版本问题。

在大多数情况下，通过还原到旧的锁定文件并进行一些复制和粘贴，我设法恢复了正常工作的版本，也许是8/10次。 现在，如果构建挂起，我现在也可以按CTRL + C强制退出该过程在某个时候无法执行的操作。 我不知道是什么解决了锁定文件中的问题，但我认为线索在我上面发布的存储库中，其中包含两个锁定文件副本，一个有效，一个无效。 这是一只怪兽。 通常，在计算机领域中，令人放心的事情是行不通的。

@steinitz运气不好吗？ 我有你提到的事情发生了。 它似乎变得更好，相当不错，但还不完美，现在几乎每次都失败了。 相当令人沮丧。

@ehowey

正如您可能想象的那样，由于此问题的断断续续性质，我不愿报告。 这是一个例子：

删除node_modules目录后，删除yarn.lock然后运行
npx yarn-upgrade-all
和
yarn install
一切都好。

然后，刚才，为了回应您的信息，我尝试了
yarn start
结果：它再次挂在
source and transform nodes

我想要做两件事：

1. 接受@georgiee的建议，以进行Webstorm的调试
   node --inspect ，看看我是否可以发现任何明显的问题
2. 将盖茨比搁置一会儿，看看是否有聪明的人可以解决问题

更新：

ctl-C创建了上述卡住的进程（它并没有用来停止令人讨厌的卡住的进程）。
然后yarn start卡在createPagesStatefully 。
ctl-C再说一次yarn start -卡在source and transform nodes
ctl-C再呆了一次（这很麻烦）-这次yarn start正常运行了

不知道该怎么做，但是确实如此。

这与我所看到的类似，今晚似乎成功构建1/10次或更少的情况似乎更糟。 从编程/编码的角度来看，这是超级奇怪的行为。 有趣的是，几天前似乎在2.15.1处表现更好，而今天在2.15.6下却表现更好。 我也想知道我们共有哪些共同点导致此错误发生。 您可以运行gatsby info --clipboard命令并将其发布吗？

显然这不是超级流行，否则会有大量的报道，但这也不只是我最初想的那样。 我们大家似乎也都在使用纱线，这对我来说是必需的，因为我正在研究纱线工作区中的主题。 我仍然能够在gatsby-starter-hello-world上重现此内容，因此我认为这是核心gatsby文件中的某些依赖性问题或冲突。

@ehowey，这是您要求的gatsby info

系统：
作业系统：macOS 10.14.6
CPU：（4）x64 Intel（R）CoreTM i7-5557U CPU @ 3.10GHz
外壳：3.2.57-/ bin / bash
二进制文件：
节点：12.9.1-/ usr / local / bin / node
纱线：1.17.3-/ usr / local / bin / yarn
npm：6.11.2-/ usr / local / bin / npm
语言：
Python：2.7.16-/ usr / local / bin / python
浏览器：
铬：76.0.3809.132
的Firefox：68.0.1
Safari：12.1.2
npmPackages：
盖茨比：^ 2.14.3 => 2.14.7
盖茨比影像：^ 2.2.14 => 2.2.15
gatsby-plugin-feed：^ 2.3.9 => 2.3.9
gatsby-plugin-i18n：^ 1.0.1 => 1.0.1
不含gatsby的插件：^ 3.0.2 => 3.0.4
gatsby-plugin-manifest：^ 2.2.9 => 2.2.10
gatsby-plugin-offline：^ 2.2.10 => 2.2.10
盖茨比插件反应头盔：^ 3.1.5 => 3.1.5
gatsby-plugin-robots-txt：^ 1.5.0 => 1.5.0
gatsby-plugin-sharp：^ 2.2.18 => 2.2.18
gatsby-plugin-sitemap：^ 2.2.9 => 2.2.9
gatsby-remark-images：^ 3.1.19 => 3.1.19
gatsby-remark-prismjs：^ 3.3.9 => 3.3.9
gatsby源文件系统：^ 2.1.18 => 2.1.18
gatsby-transformer-remark：^ 2.6.19 => 2.6.19
gatsby-transformer-sharp：^ 2.2.12 => 2.2.12
npmGlobalPackages：
gatsby-cli：2.7.40

我遇到了同样的问题：网站在Netlify上完美构建，但是挂在我的开发机器上，同时带有gatsby build和gatsby develop 。

在试用了软件包的版本之后，我注意到将gatsby-plugin-sitemap从2.2.10版本还原到2.2.9可以解决我的问题。 奇怪的是，这里的某些人似乎对2.2.9有问题，这可能意味着问题出在其他地方。

编辑：发言时间过早，但盖茨比仍然挂在“源和变换节点”和“ createPagesStatefully”步骤上，尽管频率要低得多。

@goblindegook这似乎是此特定问题的常见模式。 因为问题来来往往，似乎与天气，一天中的时间，自启动以来的时间有关...您可以相信您所做的某些事情已解决了该问题-只是让它再次出现。

也遇到了这个问题，将gatsby-plugin-sitemap降级到2.2.6，这似乎已经解决了

FWIW，我也遇到这种情况，但是既不使用yarn也不使用gatsby-plugin-sitemap 。

我的gatsby info可以帮助：

  System:
    OS: macOS 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.9.1 - /usr/local/bin/node
    npm: 6.11.2 - /usr/local/bin/npm
  Languages:
    Python: 3.7.4 - /usr/local/opt/python/libexec/bin/python
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 68.0.1
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.15.1 => 2.15.1 
    gatsby-cli: ^2.7.41 => 2.7.41 
    gatsby-image: ^2.2.15 => 2.2.15 
    gatsby-plugin-catch-links: ^2.1.6 => 2.1.6 
    gatsby-plugin-google-tagmanager: ^2.1.7 => 2.1.7 
    gatsby-plugin-manifest: ^2.2.12 => 2.2.12 
    gatsby-plugin-offline: ^3.0.0 => 3.0.0 
    gatsby-plugin-react-helmet: ^3.1.5 => 3.1.5 
    gatsby-plugin-sass: ^2.1.12 => 2.1.12 
    gatsby-plugin-sharp: ^2.2.18 => 2.2.18 
    gatsby-remark-images: ^3.1.19 => 3.1.19 
    gatsby-source-filesystem: ^2.1.18 => 2.1.18 
    gatsby-transformer-remark: ^2.6.19 => 2.6.19 
    gatsby-transformer-sharp: ^2.2.12 => 2.2.12 
    gatsby-transformer-yaml: ^2.2.7 => 2.2.7 
  npmGlobalPackages:
    gatsby-cli: 2.7.41

对我来说，使用gatsby clean清除缓存可以解决此问题。

我仍在做一些狩猎，试图找出答案。 对我来说仍然是一个问题。 有谁知道这是否与从babel 7.0.0-> 7.5.5切换有关。 这种切换发生在我开始遇到此错误的时间，并且恰好与我开始遇到问题...我一直在尝试使纱线分辨率正常工作，以将babel版本固定在7.0.0，但并未成功这个呢。

我想我可以提供一些见识-当我在向项目添加插件的一半时，在另一个终端窗口中更新了gatsby-cli时，我就开始遇到这个问题。 在我的项目中运行gatsby clean工作正常。

来自https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380-我也看到了这个问题，但是gatsby clean并没有解决。 似乎只是CLI打印输出挂起了，这就是为什么调整终端大小可以解决此问题？ ❓❗️❓❗

调整终端窗口的大小似乎可以解决我的问题！ 我还没有对其进行超级全面的测试，是否有其他人也有这个问题呢？ 多么奇怪的错误和潜在的奇怪解决方案。

我面临着完全相同的问题-Gatsby经常卡在“源和转换节点”或“ createPagesStatefully”上，并且我不使用任何源插件。 我最近才遇到“调整大小的终端窗口”修复程序，并且对修复此修复程序的方式感到困惑140％，但是确实如此。 这似乎是一个非常严重的问题！

@JaKXz-谢谢！ 这让我发疯。 该修复程序似乎在调整VS Code中的终端窗口大小。 只需向上或向下拖动它，开发任务就会愉快地进行。 我在不同的情况下测试了yarn和npm，而不是工作区。 似乎在所有这些情况下为我工作。 对我来说，它似乎比source and transform nodes更频繁地冻结或挂起createPagesStatefully 。 我现在暂时不讨论此问题，这可能需要由比我更了解的人以不太“怪异”的方式解决。

@ehowey我
您知道它是否仅在VS Code上发生吗？

我在iTerm 2上遇到了这个问题，所以它不是特定于VS Code的。

我的问题也出现在iTerm 2中

Webstorm终端，Mac终端，iTerm

调整大小的终端修复程序是否适合在不同开发环境中的所有人？

最后，调整在iTerm和VSCode上工作的终端的大小（尝试了一些尝试以重现iTerm上的问题）

调整大小的终端技巧对我来说在iTerm 2中是可靠的。

是的，调整iTerm 2的大小效果很好

如果调整大小有效，我怀疑此错误与缓冲区有关，某处需要stdout刷新。

这种问题似乎与内核+外壳相关。 节点可能以某种方式与您的内核和/或您的外壳进行交互。 我之所以这样说，是因为我似乎无法使用Linux或Windows复制问题。 我似乎找不到任何已知问题，因此a）它是Gatsby特有的代码模式的某种组合+与系统的交互，或者b）我只是不知道要问的正确问题。

如果调整终端大小可以解决问题，则节点和kqueue之间可能存在一些故障，导致事件循环中出现阻塞。 调整终端的大小将向该进程发送SIGWINCH信号，该信号会中断事件循环，从而释放事件循环并使其继续运行。

冻结时，您可以尝试在运行的进程上运行kill -SIGWINCH ${pid}吗？ 应与调整终端大小相同。

我也对是否在所有shell中都发生这种情况感兴趣。 根据到目前为止的信息，这已经在bash和zsh失败了，这可能是所有终端仿真器之间的共同因素之一。 你们可以尝试sh ， csh ， ksh ， tcsh等中的一个或多个吗？

如果问题出现在所有外壳程序中，那么我猜这就是内核处理节点事件循环的方式。 这也可能就是为什么它是一个间歇性问题。 如果某个函数获得较少的处理器时间（可能是由于可变的系统负载），它可能会阻塞太长时间，并且内核可能会在某个地方重用事件节点，从而导致死锁？ 我对api的内部不是很熟悉，但是我敢打赌source and transform nodes是文件系统IO密集型工作。 这意味着可能正在发生很多卸载工作，因此谁知道较低级别上真正发生的事情。

我认为尝试缩小此bug的表面积是一个好主意。 它最常出现在source and transform nodes ，它看起来像这样，所以也许尝试将其范围缩小到阻止了什么插件。 尝试node_modules/gatsby/dist/utils/api-runner-node.js下行添加到

+ 347       if (api === `sourceNodes`) {
+ 348         debugger;
+ 349       }
  350       resolve(runAPI(plugin, api, Object.assign({}, args, {
  351         parentSpan: apiSpan
  352       })));

然后运行node inspect node_modules/.bin/gatsby develop 。 它会在启动后立即中断，因此，当您到达debug>提示符时，必须击中c ，然后等待它继续。 当它在该debugger行上中断时，输入exec console.log(plugin) ，并记下resolve 。 然后按c继续。 只要执行此操作，直到它挂起...如果挂起。

由于事件循环的性质，我敢打赌它在调试时甚至不会挂起。 这些中断可能足以使其步入正轨。 异步错误可能是很难找到的。 如果在使用调试器时它没有挂起，请将该debugger行替换为：

reporter.log(plugin.resolve);

希望那会有所帮助。 很高兴看到是什么插件导致了该阻止。 如果我们能弄清楚，我们也许就能弄清楚需要进行哪些优化/重构才能解决这个问题。

调整大小也适用于我，我将zsh用作VSCode shell。

@ Js-Brecht-谢谢您抽出宝贵时间做出如此详细的回复。 我不确定应该在哪里输入kill -SIGWINCH ${pid} 。 在构建过程中我无法做到。

有了调试器，下面的代码就出来了……超出了我的理解范围。 我实际上卡在了调试器中，但.exit仍然有效。

⠋ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(

< {
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
⠦ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx',
<   id: '479d2e25-5a33-5a59-a290-cf1877d39ee5',
<   name: 'gatsby-plugin-mdx',
<   version: '1.0.43',
<   pluginOptions: {
<     plugins: [ [Object] ],
<     extensions: [ '.md', '.mdx' ],
<     defaultLayouts: {
<       default: '/Users/erichowey/Coding/gatsby-catalyst/themes/gatsby-theme-catalyst-core/src/components/layout.js'
<     },
<     gatsbyRemarkPlugins: [ [Object], [Object], [Object] ],
<     remarkPlugins: [ [Function: slug] ]
<   },
<   nodeAPIs: [
<     'sourceNodes',
<     'onCreateNode',
<     'onCreatePage',
<     'onCreateWebpackConfig',
<     'resolvableExtensions',
<     'preprocessSource',
<     'onCreateBabelConfig',
<     'onPreBootstrap',
<     'onPostBootstrap'
<   ],
<   browserAPIs: [ 'wrapRootElement' ],
<   ssrAPIs: [ 'wrapRootElement' ],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx'
< }
< ⠦ source and transform nodes
debug> undefined
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx',
<   id: '479d2e25-5a33-5a59-a290-cf1877d39ee5',
<   name: 'gatsby-plugin-mdx',
<   version: '1.0.43',
<   pluginOptions: {
<     plugins: [ [Object] ],
<     extensions: [ '.md', '.mdx' ],
<     defaultLayouts: {
<       default: '/Users/erichowey/Coding/gatsby-catalyst/themes/gatsby-theme-catalyst-core/src/components/layout.js'
<     },
<     gatsbyRemarkPlugins: [ [Object], [Object], [Object] ],
<     remarkPlugins: [ [Function: slug] ]
<   },
<   nodeAPIs: [
<     'sourceNodes',
<     'onCreateNode',
<     'onCreatePage',
<     'onCreateWebpackConfig',
<     'resolvableExtensions',
<     'preprocessSource',
<     'onCreateBabelConfig',
<     'onPreBootstrap',
<     'onPostBootstrap'
<   ],
<   browserAPIs: [ 'wrapRootElement' ],
<   ssrAPIs: [ 'wrapRootElement' ],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx'
< }
< ⠦ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-transformer-sharp',
<   id: '822bdf7b-a95a-5885-9351-158705910ac3',
<   name: 'gatsby-transformer-sharp',
<   version: '2.2.16',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [
<     'onCreateNode',
<     'setFieldsOnGraphQLNodeType',
<     'onPreExtractQueries',
<     'sourceNodes'
<   ],
<   browserAPIs: [],
<   ssrAPIs: [],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-transformer-sharp'
< }

⠋ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(

< {
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-source-filesystem',
<   id: '339022db-842c-55bd-8e87-d84bd74a175a',
<   name: 'gatsby-source-filesystem',
<   version: '2.1.26',
<   pluginOptions: { plugins: [], name: 'src', path: 'src/' },
<   nodeAPIs: [ 'sourceNodes', 'setFieldsOnGraphQLNodeType' ],
<   browserAPIs: [],
<   ssrAPIs: [],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-source-filesystem'
< }
< ⠋ source and transform nodes
debug> undefined
⠹ source and transform nodes
debug> exec console.log(plugin)
c
c

使用终端机的macOS Sierra调整大小对我有用。

@ehowey就是这样，我知道我对您的理解正确，在调试器中它确实挂起了？ 在这种情况下，在我看来， gatsby-source-filesystem是元凶，这对我来说很有意义……尤其是由于存在现有的相关盖茨比问题。

我想看看插件是否可以处理测试运行。 如果在运行测试时挂起，那么我认为这是查看失败原因的简便方法。 如果没有，那么...只需要做一些剖析/调试，这对我来说将很困难，因为我没有MacOS。

您可以下载主要的gatsby存储库，并运行gatsby-source-filesystem测试吗？

> git clone [email protected]:gatsbyjs/gatsby.git gatsby-js
> cd gatsby-js
> yarn bootstrap
> yarn jest -- -i './packages/gatsby-source-filesystem/src'

另外，您是否正在使用最小的复制存储库来完成所有这些工作？ 我看到gatsby-plugin-mdx运行了两次，这告诉我它不是准系统存储库。 在理想环境中，这无关紧要，但是我认为最好是运行尽可能简单的设置。 如果您无法通过最小的回购使它可靠地失败，那么请使用最一致的失败者（每次（或接近）在同一位置）

😉

kill -SIGWINCH ${pid}必须从另一个shell实例运行。 当构建挂起时，打开另一个终端窗口/选项卡，然后从那里运行命令。 这个小片段应该可以工作：

pid=$(ps -ef |grep -E 'node.*index\.js develop' |awk '{ print $2 }').
kill -SIGWINCH $pid

# Can also be run like this
kill -SIGWINCH $(ps -ef |grep -E 'node.*index\.js develop' |awk '{ print $2 }')

如果有错误，请尝试分别运行以下命令：

# Run first
ps -ef grep -E 'node.*index\.js develop'
# Example output
     UID     PID    PPID  TTY        STIME COMMAND
********   39928       1 cons0    06:47:38 /path/to/node /path/to/gatsby-cli/lib/index.js develop
# Second column is the pid you want
kill -SIGWINCH 39928

如果您在运行测试后空手而归，那么我认为进行核心转储将很有用，因此我们可以获得堆栈跟踪。 但是，一次只需要一步。

@ Js-Brecht对不起，我的回复慢了。。。这实际上只是我业余时间的业余爱好。

因此，我在gatsby hello world starter中运行了相同的操作-尽力而为。 抱歉，我以前在我遇到问题的项目的主工作区中运行过它。 我以前曾在启动程序上复制过它，所以我认为它与插件无关，而与gatsby核心中的某些东西无关。

它挂在源节点和转换节点上，提供以下输出：

< success onPreBootstrap - 0.102 s
⠋ source and transform nodes
break in node_modules/gatsby/dist/utils/api-runner-node.js:362
 360       return new Promise(resolve => {
 361         if (api === `sourceNodes`) {
>362           debugger
 363         }
 364         resolve(

< {
<   resolve: '/Users/erichowey/Coding/my-hello-world-starter/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined

< success source and transform nodes - 25.137 s

如果有帮助，这是gatsby info命令的转储：

  System:
    OS: macOS High Sierra 10.13.6
    CPU: (2) x64 Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.9.1 - /usr/local/bin/node
    Yarn: 1.17.3 - /usr/local/bin/yarn
    npm: 6.10.3 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 67.0.2
    Safari: 13.0.1
  npmPackages:
    gatsby: ^2.15.22 => 2.15.22 
  npmGlobalPackages:
    gatsby-cli: 2.7.47

附带说明-当我使用您的debug命令时，它挂在源节点和转换节点上。 当我使用gatsby development时，现在对我来说，它大多挂在createPagesStatefully上。 对不起，我知道这真的很奇怪。 老实说，我不确定从您的工作目标来看这值得做多少工作。 调整终端窗口技巧的大小每次都对我和其他人有用。 这是一个hacky修复程序，但一定不能影响许多用户，否则问题将泛滥。

这也开始在这里发生。 _resize terminal_把戏可以解决它； 很奇怪！

+1在iTerm2中不起作用，但在Terminal 🤷‍♂️中起作用

@ehowey构建过程中发生的大部分事情是由一个或另一个插件定义的。 Gatsby随它们一起提供依赖项； 我想它们可以被视为核心插件。 Gatsby核心公开了一个API，该API查找插件中定义的端点，并向它们传递一系列参数，这些参数包括核心中定义的动作/对象。 所以是的，正在发生的事情可能发生在核心中，但是它首先必须调用一个插件，并且这些插件为API定义了特定的上下文。 我正在尝试确定导致构建挂起的上下文，并且还需要验证插件本身没有发生此问题。

我可以让您更改这些行吗？

 360       return new Promise(resolve => {
-361         if (api === `sourceNodes`) {
-362           debugger
-363         }
+364         reporter.log(`${api}\t${plugin.name}`)
 365         resolve(

请运行此命令，然后复制/粘贴整个输出（甚至可以将其作为.txt文件附加到您的响应中）。 它将变得更加冗长，并且很多信息可能都是不必要的，但是🤷。

完成之后，我想看看增加节点的线程池是否有所作为。 我注意到其他提到相同或相似问题的问题。 大多数情况下，它们发生在source and transform ，有人谈论这个阶段将永远或完全锁定。 因此，我想看看它是否恰好是文件系统io中的某种死锁...异步文件系统访问由节点转移到不同的线程，并且默认情况下，节点只有4个线程池供用户空间使用。 如果这些已满，并且需要进行更多卸载，则任务将在主事件循环中排队，等待线程。 这可能会使整个程序陷入停顿……直到线程可用。 Gatsby在文件系统上维护了一个高速缓存，所以也许某个地方发生了冲突，并且如果发生某种死锁，那么线程可能在继续之前等待超时/中断，并且是否有数十个（甚至数百个）文件系统访问事件的发生，它们可能都在等待相同的超时，并导致一切堆积。 您会看到这可能导致等待时间增长很快。

增加池的大小可能有助于减轻某些流量...或者，也可能以相同的方式发生，只是线程更多more。
尝试以下命令：

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht更改线程池大小似乎并没有多大区别。
我从标准gatsby develop命令获得以下输出，并带有您上面提到的更改。 仍在基本的hello-world gatsby启动程序上。

Erics-MBP:my-hello-world-starter erichowey$ gatsby develop
success open and validate gatsby-configs - 0.050 s
success load plugins - 0.119 s
success onPreInit - 0.036 s
success initialize cache - 0.050 s
success copy gatsby files - 0.281 s
onPreBootstrap  load-babel-config
success onPreBootstrap - 0.131 s
sourceNodes     internal-data-bridge
success source and transform nodes - 0.105 s
success Add explicit types - 0.030 s
success Add inferred types - 0.186 s
success Processing types - 0.145 s
success building schema - 0.535 s
success createPages - 0.032 s
createPagesStatefully   dev-404-page
onCreatePage    internal-data-bridge
onCreatePage    prod-404
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
onCreatePage    internal-data-bridge
onCreatePage    prod-404
success createPagesStatefully - 9.098 s
success onPreExtractQueries - 0.030 s
success update schema - 0.129 s
success extract queries from components - 0.336 s
success write out requires - 0.057 s
success write out redirect data - 0.044 s
success onPostBootstrap - 0.045 s
⠀
info bootstrap finished - 16.437 s
⠀
success run static queries - 0.038 s
success run page queries - 0.109 s — 2/2 27.65 queries/second
onCreateWebpackConfig   webpack-theme-component-shadowing
onCreateWebpackConfig   webpack-theme-component-shadowing
success start webpack server - 1.506 s — 1/1 4.63 pages/second
 DONE  Compiled successfully in 4699ms

这是一个挂在createPagesStatefully上的示例。 我通过调整终端窗口的大小来继续构建。 在某种程度上可能是罪魁祸首的internal-data-bridge是多少？ 到目前为止，您已经要求我运行的两个命令都具有这种功能。

您能显示它挂在哪条线上吗？

createPagesStatefully dev-404-page

我不确定100％是否存在dev-404-page部分，但是它挂在createPagesStatefully的第一个实例上

谢谢。 如果您不介意的话，我现在想尝试更多更改。

请更新以下文件中的指示行：

node_modules/gatsby/dist/internal-plugins/internal-data-bridge/gatsby-node.js

- 114   chokidar.watch(pathToGatsbyConfig).on(`change`, () => {
+ 114   chokidar.watch(pathToGatsbyConfig, { useFsEvents: false }).on(`change`, () => {

node_modules/gatsby/dist/internal-plugins/dev-404-page/gatsby-node.js

- 30     chokidar.watch(source).on(`change`, () => copy()).on(`ready`, () => done());
+ 30     chokidar.watch(source, { useFsEvents: false }).on(`change`, () => copy()).on(`ready`, () => done());

node_modules/gatsby-page-utils/dist/watch-directory.js

  26               chokidar.watch(glob, {
  27                 cwd: path,
+ 28                 useFsEvents: false,
  29               }).on("add", function (path) {

node_modules/gatsby/dist/utils/get-static-dir.js

- 51   chokidar.watch(staticDir).on(`add`, path => {
+ 51   chokidar.watch(staticDir, { useFsEvents: false }).on(`add`, path => {

node_modules/gatsby/dist/query/query-watcher.js

- 237   watcher = chokidar.watch([slash(path.join(rootDir, `/src/**/*.{js,jsx,ts,tsx}`)), ...packagePaths]).on(`change`, path => {
+ 237   watcher = chokidar.watch([slash(path.join(rootDir, `/src/**/*.{js,jsx,ts,tsx}`)), ...packagePaths], { useFsEvents: false }).on(`change`, path => {

我怀疑chokidar在这里可能有错。 大约一个月前，它已升级到v3.x，看起来他们要么开始使用fsevents ，要么他们做了一些与fsevents相关的错误行为。 他们有一些未解决的问题，类似于我们在这里面临的问题，使用chokidar.watch()时节点挂起。 这似乎很合适，因为由于fsevents是Mac进程而已本地化到MacOS，并且该构建似乎在使用它的模块或正在写出/处理文件的模块中失败。可能会被监视。

chokidar.watch()存在于gatsby-source-filesystem ，这就是您的其他仓库@ehowey失败的地方。 更不用说， gatsby-source-filesystem不会在您的最小存储库中调用，这解释了为什么它超过source and transform 。 在internal-data-bridge chokidar之前有query-watcher ）。 但是，我相信internal-data-bridge是运行调试器时挂起的原因。 在直接运行中，可能会影响构建的后期阶段。

让我知道这是否解决了问题，或者是否使问题超出了以往。 ：交叉手指：

@ Js-Brecht你要去某个地方！ 我大概运行了15次gatsby develop 。 它从未挂在source and transform nodes或createPagesStatefully但似乎在start webpack server上挂了2/10次。 我也可以通过调整大小的终端技巧来解决这个问题。 您是否有可能错过了与start webpack server相关的chokidar / fsevents实例？

附带说明一下，如果这与开发有任何关系，它似乎也比以前更快地完成了开发过程。

真的很高兴听到。 我确实故意留了一个chokidar实例，它是在完成引导程序并启动服务器之后的。 在startServer()函数的末尾，它位于node_modules/gatsby/dist/commands/develop.js 。 我现在不在电脑旁，或者给您一个差异。

您可以通过执行以下操作找到确切的行：

cat node_modules/gatsby/dist/commands/develop.js |grep -n ‘chokidar’

我非常确定，如果这能修复引导程序，那么它仍然必须挂在服务器上。 让我知道是否进行了更改，使其能够可靠运行，我将提交PR，并告知他人。

我实际上并不感到惊讶，它使它运行得更快。 在准系统的构建一般项目以我也许一秒钟，我看到了一定的阶段，一些疯狂的长运行时间在调试输出。 fsevents应该可以加快速度，并减轻CPU的负担，但是有趣的事情正在使它卡住。

@ Js-Brecht我的帽子给你戴了。 我不知道你是怎么把兔子从帽子里拉出来的，而虫子却从远处固定了这么奇怪的一只，但是做得很好！ 我将等待diff对develop.js进行更改，因为我不想更改错误的内容，但是我怀疑它将解决此问题，因为它在启动服务器时挂在了最后一步的时间。

这是差异：

node_modules/gatsby/dist/commands/develop.js

- 337   chokidar.watch(watchGlobs).on(`change`, async () => {
+ 337   chokidar.watch(watchGlobs, { useFsEvents: false }).on(`change`, async () => {

进行所有这些测试非常感谢您的帮助。 这是一个棘手的问题，但它是一个深入研究MacOS内部的机会，我总是喜欢学习新事物：slightly_smiling_face：

请让我知道进展如何； ：sweat_微笑：还没有完全走出困境

作品！ 我刚运行gatsby develop 10次​​以上，就可以正常工作了。 感谢您的协助。 希望这对我们这方面的人们有所改善！

大！ 稍等片刻，在这里，我会整理一个PR。 完成后，您将可以在我的存储库中使用gatsby-dev-cli ，以便在发布补丁之前拥有一个工作的开发环境（如果您不熟悉gatsby-dev-cli ，我可以救命）。 无论如何，我可能会尝试招募您来测试更改，因为我没有正确的操作系统...在遇到此问题的线程上，其他人也是如此。

完成后，我会在这里发布。

我发现了另一个也会导致此症状的单独问题-https: //github.com/gatsbyjs/gatsby/issues/17935

如果有人使用LokiJS且调整终端大小无法解决问题，则很可能是我发现的问题。

大家好， @ ehowey ，请查看PR＃17938。 如果有人愿意测试，请这样做，并在PR上打上一行。

您可以使用gatsby-dev-cli捕获我的存储库，并将其用作站点中的gatsby源。 首先，您需要gatsby-dev-cli

# Use your package manager of choice, and install globally
npm install -g gatsby-dev-cli

然后，只需克隆存储库，然后对其进行引导。

git clone --single-branch -b macos-fsevents-fix https://github.com/Js-Brecht/gatsby
cd gatsby
yarn bootstrap
# Set the target repo path for gatsby-dev
gatsby-dev -p "${PWD}"

然后转到您要使用回购协议的站点，然后运行gatsby-dev

# Disable file watching, unless you intend on making changes to the gatsby repo
gatsby-dev --scan-once

就我而言，我正在使用OSX和IntelliJ，我必须：

• 在IntelliJ中关闭项目
• 再试一次（ npm start ）
• 并在Intellij中重新打开该项目
  我想这个问题与IntelliJ索引文件有关

@steinitz，@rheinardkorf，@ hbthen3rd，@sharvit，@JaKXz，@emilyaviva，@MaximeHeckel

你们中有人愿意测试＃17938吗？

我应该可以在今晚晚些时候回家时看看。 感谢您为此所做的所有工作！
2019年10月1日上午6:00（00:23），Jeremy Albright [email protected]写道：

@steinitz，@rheinardkorf，@ hbthen3rd，@sharvit，@JaKXz，@emilyaviva，@MaximeHeckel
你们中有人愿意测试＃17938吗？
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看，或使该线程静音。

此修复程序有任何更新吗？ 在尝试[Firebase Source] Fetching data for ...之后，对我和我的朋友来说，它在源和转换节点上都冻结

不幸的是，调整终端的大小似乎无法为我们解决

@ rishabhaggarwal2还有一个类似的问题，听起来可能是您正在遇到的问题，它会在从在线源中检索数据时挂起。 您可以尝试使用GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop吗？

也看到这一点。 在lumen启动上根本无法在本地运行gatsby develop 。 一直挂在createPageStatefully或source and transform nodes

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

对于其他发现此问题的人，请尝试

CHOKIDAR_USEPOLLING=1 gatsby develop

那应该在MacOS上禁用fsevents ，这似乎是一个可靠的解决方法。

@ Js-Brecht我确认它似乎比这里提到的其他解决方法更永久地修复它。 感谢分享。

@steinitz，您永久地说“更多”。 您是说使用该开关时仍然会发生这种情况吗？

@ Js-Brecht不，抱歉，不清楚。

我在暗示一个事实，即其他解决方法，包括我自己的解决方法，似乎可以工作一段时间，但问题仍然存在。 对于您的解决方案，我进行了更改并重新运行gatsby（通过您的增强功能）进行开发，从而激发了该解决方案，但是构建仍在继续。

就是说，这是一次过山车之旅，所以我保持情绪上的准备：微笑：问题再次出现。

要明确：到目前为止，很好。

糟糕，更新：在发布此消息之前，我重新启动了WebStorm进行最终测试，现在将其挂在WebStorm终端的source and transform nodes上。

对于其他发现此问题的人，请尝试

CHOKIDAR_USEPOLLING=1 gatsby develop

那应该在MacOS上禁用fsevents ，这似乎是一个可靠的解决方法。

@ Js-Brecht我正在使用ubutu 18.04，偶尔会遇到相同的问题。 我的操作系统有什么建议吗？ 您能否提供有关此问题可能原因的详细信息？

由于@ Js-Brecht和@RomanHotsiy的辛勤工作，这一问题已得到解决。 这是fsevents中的上游问题，远远超出了我自己能想到的范围，一旦实现了这些更改并将其从fsevents迁移到gatsby本身，就应该在以后的更新中修复。 现在，一种可靠的解决方法是调整终端窗口的大小，这里有一种方法可以在您的仓库中对其进行修复： https :

在修复程序向下游迁移到gatsby本身之前，我将一直保持开放状态。

@ Boty22 Ubuntu不使用fsevents ，因此可能有所不同。 从远程位置检索数据时遇到了一些问题。 有关更正并发问题的详细信息，请参阅＃6654和＃17940。

快速提问：调整终端大小是否有帮助？ 如果是这样，则可能与此问题类似。

@ Js-Brecht调整终端大小对Ubuntu没有帮助。 我正在使用插件gatsby-source-airtable BTW从AirTable表中检索数据

那可能是问题所在。 查看此评论。 如果这样不起作用，最好重新开一张票

@steinitz对不起，我想念您的评论。 您可以尝试＃17938中描述的修复程序吗？ 更具体地说，在这里和这里。 如果它不起作用，那么您的情况可能还有更多事情要做。

自从提到以来， CHOKIDAR_USEPOLLING=1 gatsby develop没有任何问题。

感谢您的解决方法@ Js-Brecht

当我执行gatsby构建时，在2.15.28中也看到了这一点。 我需要停止在另一个终端上进行的gatsby开发吗？ 断断续续地发生

在未运行开发服务器的情况下再次发生。 不过，通过遵循博客教程可以得到一个简单的博客。

似乎几乎所有其他运行。 我在Mac上顺便说一句

@canvaspixels调整终端窗口的大小是否会使您的构建https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991

@RomanHotsiy确实可以排序！ 谢谢！

大家好， fsevents的修补版本已经发布。 您应该能够简单地删除yarn.lock文件，然后再次运行yarn。 您的每个依赖项都应自动选择[email protected] ，这应该可以解决此问题。

注意-删除整个yarn.lock文件也可能导致其他软件包升级。

如果您使用yarn则另一个更精确的选择是只删除与fsevents中与yarn.lock然后重新运行yarn 。 这将仅导致受影响的软件包被升级。 因此，例如，我删除了以下几行：

- 
- fsevents@^2.0.6:
-   version "2.0.7"
-   resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.0.7.tgz#382c9b443c6cbac4c57187cdda23aa3bf1ccfc2a"
-   integrity sha512-a7YT0SV3RB+DjYcppwVDLtn13UQnmg0SWZS7ezZD0UjnLwXmy8Zm21GMVGLaFGimIqcvyMQaOJBrop8MyOp1kQ==

另一种方法是使用Yarn的resolutions功能（https://yarnpkg.com/lang/zh-CN/docs/selective-version-resolutions/）。 通过将以下内容添加到package.json ，然后运行yarn ，它还将升级传递依存关系并更新yarn.lock文件：

  "resolutions": {
    "fsevents": "^2.1.1"
  }

完成此操作并更新了锁文件后，可以再次从package.json删除resolutions属性。

编辑：删除了以前的错误版本的说明。

您还可以运行yarn upgrade chokidar@latest 。 那应该使用正确版本的fsevents重建锁定文件，而不用碰其他任何东西

等一下。 只有将chokidar作为直接依赖项🙄。 忘记。 @karlhorky是正确的

我正在使用npm 。 删除node_modules ，先运行npm i --save [email protected] ，然后再运行npm i ，这对我来说很有效。 花了19秒钟启动时间，我以gatsby-lumen-starter为基础。

-编辑：

我实际上完成了我的工作，转而使用Netlify，由于fsevents （ error [email protected]: The platform 'linux' is incompatible with this module ），它完全无法构建。

我切换到yarn并遇到了同样的问题，所以我将fsevents完全删除

遇到了同样的问题，无法追踪原因。 这在Mac和PC上都发生在我身上。 可以尝试将其与互联网速度相关联，但是当我连接到高速网络时，这也发生在我身上。 现在似乎对我有用的是将其添加到我的环境中

GATSBY_CONCURRENT_DOWNLOAD=5

并使用--v8-pool-size=128

就我而言，这似乎是我在osx上的防火墙提示。 如果我的速度足够快，可以允许或拒绝来自外部的连接，那么它将成功完成。 问题是，弹出提示对话框的瞬间，随着Gatsby的继续而消失，然后挂在上面提到的许多步骤之一上失败。
选项：

• 禁用防火墙（没有防火墙）
• 将盖茨比列入白名单（在项目和升级之间不一致）
• 找到一种方法来暂停提示，直到用户选择选项
• 默认绑定地址到本地主机（不需要提示以接受传入连接）。

@thomasthep开发服务器的默认绑定地址已经是localhost。 除非您告诉它使用外部IP地址（或0.0.0.0），否则它甚至不会监听外部连接。 即便如此，它也不会启动引导服务器/构建之后才启动开发服务器。 如果是导致防火墙提示的引导程序，则它与您使用的插件有更多关系，因为Gatsby在默认状态下不会连接到Internet。

一般来说，甚至不应有任何“来自外部”的连接。 即使插件正在从外部来源收集信息，该连接也源自您的本地主机，而不是来自外部来源，根据我的经验，由于大多数防火墙都已配置，因此大多数防火墙通常将其视为“已建立的连接”接受任何传出连接。

如果您的防火墙配置为阻止进程，而不仅仅是连接，则可以看到这种情况。 在这种情况下，需要将Node列入白名单。

需要更多信息以真正了解您为什么会这样。 不过，开张新票可能会更有效。 这与导致问题的MacOS上的fsevents有关，并且已经解决，这就是为什么现在关闭它的原因。 任何与fsevents不相关的内容都应该有自己的问题，以引起应有的关注。

作为记录，如果您的GraphQL服务器在调试模式下运行并且在断点处停止，也可能发生这种情况。

作为记录：当我添加gatsby-source-s3-image时，这开始发生在我身上，而s3存储桶达到了100幅图像。 它会在source and transform nodes阶段浏览所有145张图像，然后永远挂在那里。 它仍然在发生，我已经尝试了上面的修复程序。 幸运的是，它经过5-6次尝试后仍然有效，因此我没有受到阻碍。

奇怪地调整终端窗口的大小对我有用

对我来说，按此处所述限制并发下载似乎有所帮助。

我在.env文件中添加了以下行。 默认值为200。
GATSBY_CONCURRENT_DOWNLOAD=50

不确定是否可以解决您的问题，但也许可以帮助某人:)

@ rishabhaggarwal2还有一个类似的问题，听起来可能是您正在遇到的问题，它会在从在线源中检索数据时挂起。 您可以尝试使用GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop吗？

谢谢，这对我来说已经解决了。 自从我从第三方网站提取大量内容以来，它一直挂着下载内容。 （97％-到目前为止很近）