Gatsby: [fseventsバグ] MacOSの「ソースノードとトランスフォームノード」/「createPagesStatefully」でスタック

更新-gatsby-node.jsファイルのコメントアウトをテストしたところ、ビルドが1回進行しましたが、再試行してこれを実行すると、同じ場所で再びスタックしました。

これは私の古いコンピューターである2010Macbook Pro（8GB RAMとSSDにアップグレードされた）がまだ私を止めていないためである可能性はありますが、その日数は限られていることを私は知っています。 これは私にとっての趣味であり、私には幼い子供がいるので、アップグレードされたRAMとSSDで問題なく動作したため、新しいコンピューターにお金をかけることはありませんでした。

私は安定していた最後のバージョンであるgatsby2.13.52に戻ろうとしましたが、16.8.6に反応するように戻そうとしました。

興味深いことに、16.8.6にリアクションを戻したときに、一度正常にビルドできましたが、その後、同じ場所でハングアップしました。これは、私にとって本当に奇妙な動作です。

また、まれに、理由もなく、正常に構築できることを識別できません。 これが起こるときの韻や理由はないようです。 これを引き起こしている可能性のあるパターンやエラーを探すのに数時間を費やしましたが、何も見つかりませんでした。 https://github.com/gatsbyjs/gatsby/issues/6654を確認し、そこにあるいくつかのアイテムを試しましたが、役に立ちませんでした。

これは、コードに識別可能な変更がなくても動作が変更されているように見えるため、これまでに遭遇した中で最も奇妙なバグの1つです。 ビルドがソースノードとトランスフォームノードでハングする場合（60％の時間）、ページをステートフルに作成する場合（20％）でハングする場合、正常にビルドされる場合（20％）があります。 コード行を変更せずに、これら3つの動作すべてを表示するようにしました。

私は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でハングします

こんにちは、

私はほとんど何もできませんが、多くのギャツビースターターでこの問題が発生していることを確認します。 そして、ご指摘のとおり、「ソースノードとトランスフォームノード」または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」からロックファイルをコピーしてこれを使用すれば、最小限の実装を構築することができます。 だから私の現在の理論は、この問題を引き起こしている私のロックファイルにある種のバージョンの問題があるということですが、私はここで立ち往生しています。

また、自作のインストールをすべて削除し、ノード、yarn、gitなどを再インストールしました。それが面白いビジネスではないことを確認するためです。

これを上げてくれてありがとう@ehowey ....それはかなり断続的であるため、私だけだと思いました（しかし、50％以上の⠙ source and transform nodesを使い続けると、通常は端末を強制終了する必要があります。

何か見つけたらお知らせします。 そして、私もこのスレッドを見ます。

@ georgiee --inspect情報をありがとう。 WebStormでノードデバッグを機能させることができるかどうかを確認します。

最小限の複製というあなたの考えも好きです。 しかし、ギャツビーをもう少し深く理解している間は時間がかかります。

現在、「ソースノードと変換ノード」にぶら下がっています。 まれに、createPagesStatefullyになり、そこでハングします。 それ以外の場合は正常にビルドされます。

脆弱な依存関係を修正するために「ヤーンアップグレード」を実行した後、現在同じ問題に直面しています。 これが私の設定です：

システム：
OS：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
ブラウザ：
Chrome：76.0.3809.132
Firefox：68.0.2
Safari：13.0
npmPackages：
ギャツビー：^ 2.13.42 => 2.14.7
gatsby-background-image：^ 0.8.3 => 0.8.6
gatsby-image：^ 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-remark-responsive-iframe：^ 2.2.5 => 2.2.10
gatsby-source-filesystem：^ 2.1.6 => 2.1.18
gatsby-transformer-備考：^ 2.6.12 => 2.6.19
gatsby-transformer-sharp：^ 2.2.5 => 2.2.12

脆弱な依存関係を修正するために「ヤーンアップグレード」を実行した後、現在同じ問題に直面しています。 これが私の設定です：

更新：古い「yarn.lock」ファイルを復元することで、なんとか修正できました。

@ hbthen3rd

更新：古い「yarn.lock」ファイルを復元することで、なんとか修正できました。

私の経験では、問題は明確な理由もなく解消され、後で戻るだけです。 糸.lockを復元しても問題が再発する場合があります。 投稿してください。

これは、gatsby-starter-hello-worldを使用した最小限の複製です。

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

リポジトリに含まれている現在のロックファイルは、私にとって失敗したものです。 yarn-working.lockとyarn-notworking.lockのリポジトリにもコピーを含めました。 うまくいけば、それは誰かがトラブルシューティングするのをより簡単にするでしょう。

私の現在の環境：

システム：
OS：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
ブラウザ：
Chrome：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から2.2.6ダウングレードすると、 yarn develop問題が解決しました。

   • gatsby-plugin-sitemapは開発ビルドに影響を与えないはずなので、これは奇妙なことです。

2. yarn buildまだ機能しませんが、構成からgatsby-plugin-sitemapを削除すると、 yarn buildが再び機能します。

@sharvit私の場合、これが機能しなかったことを報告できます。 それがあなたのためにそれを修正してくれてうれしいです、私はそれが最終的にロックファイルと関係があると思いますそしていくつかの奇妙なバージョンの問題はロックファイルの奥深くにあります。

古いロックファイルに戻ってコピーアンドペーストを行うことで、ほとんどの場合、おそらく8/10回、動作するビルドに戻ることができました。 また、CTRL + Cを使用して、ビルドがハングしている場合にビルドを強制的に終了することもできます。これは、このプロセスのある時点では実行できませんでした。 ロックファイルで何が修正されるかはわかりませんが、手がかりは上記のリポジトリにあり、ロックファイルのコピーが2つあり、1つは機能し、もう1つは機能しないと思います。 これはバグの奇妙な獣です。 通常、コンピュータランドでは、物事は安心して機能するか、機能しません。

@steinitz運が良かったですか？ 私はあなたが言ったことを起こさせました。 それは良くなり、かなり良くなったように見えましたが、完璧ではなく、今ではほぼ毎回失敗しています。 かなりイライラする。

@ehowey

ご想像のとおり、この問題は何度も繰り返される性質があるため、報告することを躊躇します。 これがその好例です：

node_modulesディレクトリを削除した後、yarn.lockを削除してから実行します
npx yarn-upgrade-all
そして
yarn install
すべてが順調でした。

それでは、今、あなたのメッセージに応えて、
yarn start
結果：で再びハングします
source and transform nodes

私は2つの賢明なことをする必要があると思います：

1. @georgieeのアドバイスを受けて、Webstormのデバッグを
   node --inspectそして明らかな問題を見つけることができるかどうかを確認します
2. ギャツビーをしばらく脇に置いて、賢い人が問題を解決するかどうかを確認します

更新：

ctl-上記のスタックプロセスをCしました（これは、二重に煩わしいスタックプロセスを停止するために使用されませんでした）。
その後、 yarn startがcreatePagesStatefullyスタックしました。
ctl-C'dもう一度、別の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です

システム：
OS：macOS 10.14.6
CPU：（4）x64 Intel（R）Core（TM）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
ブラウザ：
Chrome：76.0.3809.132
Firefox：68.0.1
Safari：12.1.2
npmPackages：
ギャツビー：^ 2.14.3 => 2.14.7
gatsby-image：^ 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-plugin-less：^ 3.0.2 => 3.0.4
gatsby-plugin-manifest：^ 2.2.9 => 2.2.10
gatsby-plugin-offline：^ 2.2.10 => 2.2.10
gatsby-plugin-react-helmet：^ 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-source-filesystem：^ 2.1.18 => 2.1.18
gatsby-transformer-備考：^ 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に問題があるようです。これは、問題が別の場所にあることを意味している可能性があります。

編集：話が早すぎたため、Gatsbyは「ソースノードと変換ノード」および「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キャッシュをクリーンアップすることで問題が解決しました。

私はまだこれを理解しようとして、いくつかの狩猟をしています。 それでも私には問題があります。 これがbabel7.0.0-> 7.5.5からの切り替えに関連する可能性があるかどうか誰かが知っていますか？ この切り替えは、このバグが発生し始めた頃に発生し、問題が発生し始めたのと一致します... 7.0.0でバベルバージョンをペグするために糸の解像度を機能させようとしましたが、成功しませんでしたこれはまだ。

私はいくつかの洞察を提供できると思います-プロジェクトにプラグインを追加する途中で、別のターミナルウィンドウでgatsby-cliを更新したときに、この問題が発生し始めました。 私のプロジェクトでgatsby cleanを実行するとうまくいきました。

https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380から-この問題も発生していますが、 gatsby cleanでは解決しませんでした。 CLIプリントアウトがハングしているだけのようですが、ターミナルのサイズを変更すると修正されるのはなぜですか？ 🤷‍♂😕❓❗️

ターミナルウィンドウのサイズを変更すると、修正されたようです。 私はそれをあまり広範囲にテストしていません、この問題を抱えている他の何人かの人々もこれを試すことができますか？ なんて奇妙なバグであり、潜在的に奇妙な解決策でしょう。

私はまったく同じ問題に直面しています。gatsbyは「ソースノードとトランスフォームノード」または「createPagesStatefully」で頻繁にスタックし、ソースプラグインを使用していません。 私は最近「ターミナルウィンドウのサイズ変更」の修正に遭遇し、これが一体どのように修正するかについて140％困惑していますが、実際に修正しています。 これはかなり深刻な問題のようです！

@ JaKXz-ありがとう！ これは私を狂わせていました。 修正は、VSCodeでターミナルウィンドウのサイズを変更しているようです。 少し上下にドラッグするだけで、開発タスクが楽しく動きます。 私は、yarnとnpmの両方、ワークスペースではなく、いくつかの異なるケースでテストしました。 私にとっては、これらすべてのケースで機能しているように見えました。 また、私にとっては、 source and transform nodesよりも頻繁にcreatePagesStatefullyでフリーズまたはハングするようです。 とりあえずこの問題を開いたままにしておきます。これは、私よりもノウハウのある人が、「ハッキー」な方法で修正する必要があるかもしれません。

@ehowey私は同じ問題を抱えており、
それがVSCodeでのみ発生するかどうか知っていますか？

私はiTerm2でこの問題を抱えているので、VSCode固有ではありません。

私の問題はiTerm2にもありました

Webstormターミナル、Macターミナル、iTerm

ターミナルのサイズ変更の修正は、さまざまな開発環境のすべての人にとって機能しましたか？

私の側では、ターミナルのサイズ変更はiTermとVSCodeで機能しました（iTermで問題を再現するために数回試みました）

ターミナルのサイズ変更のトリックは、iTerm2で確実に機能します。

はい、iTerm2のサイズ変更は完全に機能します

サイズ変更が機能する場合、このバグは関連するバッファであると思われます。どこかにstdoutフラッシュが必要です。

この種の問題は、カーネルとシェルに関連する問題のようです。 おそらく、何らかの方法でノードがカーネルやシェルと相互作用します。 LinuxまたはWindowsを使用して問題を再現できないように思われるため、これを言うだけです。 既知の問題を見つけることができないようです。そのため、a）Gatsbyに固有のコードパターンとシステムとの相互作用の組み合わせであるか、b）質問する正しい質問がまだわかりません。

ターミナルのサイズを変更すると問題が解決する場合は、ノードとkqueue間でグリッチが発生し、イベントループでブロックが発生している可能性があります。 端末のサイズを変更すると、プロセスにSIGWINCH信号が送信され、イベントループが中断されて解放され、続行できるようになります。

実行中のプロセスがフリーズしたときにkill -SIGWINCH ${pid}を実行してみてください。 端末のサイズ変更と同じように機能する必要があります。

これがすべてのシェルで発生するかどうかにも興味があります。 これまでの情報に基づくと、これはbashとzshで失敗しており、これはおそらくすべてのターミナルエミュレーターに共通する要因の1つです。 sh 、 csh 、 ksh 、 tcshなどの1つ以上を試してみませんか？

すべてのシェルで問題が発生した場合は、カーネルがノードのイベントループを処理している方法だと思います。 これが断続的な問題である理由でもあります。 一部の関数のプロセッサ時間が短くなると（おそらくシステム負荷が変動するため）、ブロックが長すぎる可能性があり、カーネルがどこかでイベントノードを再利用しようとして、デッドロックが発生する可能性がありますか？ 私はAPIの内部にあまり精通していませんが、 source and transform nodesはかなりファイルシステムのIOを集中的に使用しているに違いありません。 つまり、おそらく多くのオフロードが発生しているので、下位レベルで実際に何が起こっているのかは誰にもわかりません。

このバグの表面積を絞り込んでみるのもいいと思います。 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);

うまくいけば、それは何かを上げるでしょう。 どのプラグインがブロックを引き起こしているのかを確認すると便利です。 それを理解できれば、これを整理するために何を最適化/リファクタリングする必要があるかを理解できるかもしれません。

サイズ変更も機能します。VSCodeシェルとしてzshを使用します。

@ 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が2回実行されたことがわかります。これは、それが最低限のリポジトリではないことを示しています。 完璧な世界では、それは問題ではありませんが、できるだけ単純なセットアップを実行する方が良いと思います。 最小限のレポで確実に失敗させることができない場合は、最も一貫して失敗した方を使用してください（同じ場所で、毎回（または近くで））

😉

kill -SIGWINCH ${pid}は、別のシェルインスタンスから実行する必要があります。 ビルドがハングした場合は、別のターミナルウィンドウ/タブを開き、そこからコマンドを実行します。 この小さなスニペットは機能する

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応答が遅くなってすみません...これは、私が夕方の暇なときに行う単なる趣味です。

だから私はgatsbyhello worldスターターの中で同じことを実行しました-あなたが得ることができるのと同じくらい骨の折れるものです。 申し訳ありませんが、以前問題が発生していたプロジェクトのメインワークスペースで実行しました。 以前にスターターで複製したことがあるので、プラグインではなく、ギャツビーのコアにあるものに関連していると思います。

ソースノードとトランスフォームノードでハングし、次の出力が表示されます。

< 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

これは、役立つ場合のgatsbyinfoコマンドからのダンプです。

  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

補足として-デバッグコマンドを使用すると、ソースノードとトランスフォームノードでハングします。 gatsby developmentを使用すると、ほとんどがcreatePagesStatefullyにぶら下がっています。 申し訳ありませんが、これは本当に奇妙なものです。 正直なところ、あなたの終わりからどれだけの仕事が価値があるのか​​わかりません。 ターミナルウィンドウのサイズ変更のトリックは、私や他の人にとって毎回機能します。 これはハッキーな修正ですが、多くのユーザーに影響を与えてはなりません。そうしないと、問題が殺到します。

これはここでも起こり始めています。 _ターミナルのサイズ変更_トリックはそれを解決します。 非常に奇妙な！

+1 iTerm2では機能しませんが、ターミナルでは機能します🤷‍♂️

@ehoweyビルド中に発生することの大部分は、1つのプラグインまたは別のプラグインによって定義されます。 Gatsbyは依存関係として同梱されています。 それらはコアプラグインと見なすことができると思います。 Gatsbyコアは、プラグインで定義されたエンドポイントを検索する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はファイルシステムにキャッシュを保持しているため、どこかで衝突が発生している可能性があります。何らかのデッドロックが発生している場合は、スレッドがタイムアウト/割り込みを待ってから先に進みます。数十（または数百）の場合もあります。ファイルシステムアクセスイベントの場合、それらはすべて同じタイムアウトを待機し、すべてが積み重なる可能性があります。 これにより、待機時間がかなり急速に長くなる可能性があることがわかります。

プールサイズを増やすと、一部のトラフィックを軽減できる可能性があります...または、スレッドを増やすだけで、同じように発生する可能性があります😆。
次のコマンドを試してください。

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brechtスレッドプールのサイズを変更しても、大きな違いは見られませんでした。
上記の変更を加えた標準のgatsby developコマンドから次の出力が得られます。 まだ基本的なhello-worldgatsbyスターターです。

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

dev-404-page部分がまだそこにあるかどうかは100％わかりませんが、 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があるので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が、デバッガーの実行中にハングした理由だと思います。 ストレートスルー実行では、ビルドの後の段階に影響を与える可能性がありました。

これで問題が解決するかどうか、または以前よりもさらに問題が解決するかどうかをお知らせください。 ：crossed_fingers：

@ Js-ブレヒトあなたはどこかに行きます！ 私はgatsby developおそらく15回実行しました。 source and transform nodesまたはcreatePagesStatefullyにハングすることはありませんstart webpack server 2/10回ハングするように見えました。 ターミナルのサイズ変更のトリックと一緒にこれをぶつけることもできます。 start webpack server関連するchokidar / fseventsのインスタンスを見逃した可能性はありますか？

補足として、それがそれと関係がある場合、それは以前よりもはるかに速く開発プロセスのステップを通過するようにも見えましたか？

聞いて本当に良かったです。 わざとchokidarのインスタンスを1つ残しましたが、それはブートストラップを終了してサーバーを起動した直後です。 startServer()関数の終わりに向かってnode_modules/gatsby/dist/commands/develop.jsにあります。 私は今コンピュータを使用していません、または私はあなたに差分を与えるでしょう。

次の手順を実行すると、正確な行を見つけることができます。

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

これでブートストラップが修正された場合でも、サーバーでハングする必要があると確信していました。 それを変更することで確実に動作するかどうか教えてください。PRを提出して、人々に知らせるようにします。

私はそれがそれをより速く走らせることに実際に驚かない。 ベアボーンのビルドは通常、プロジェクト多分秒私を取り、私はあなたのデバッグ出力に特定の段階のためのいくつかのクレイジーな長い実行時間を見ました。 fseventsは物事をスピードアップし、CPUから多くの負荷を取り除くことになっていますが、代わりに、何かおかしなことが起こって行き詰まってしまいます。

@ Js-ブレヒト私の帽子はあなたに消えます。 どうやってそのウサギを帽子から引き抜いたのかわかりません。バグは遠くからそのような奇妙なウサギを修正しましたが、うまくいきました！ 間違ったものを変更したくないので、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_smile :。

動作します！ gatsby develop 10回以上実行したところ、問題なく動作しました。 これを調査するのにあなたの助けをありがとう。 うまくいけば、これはこれを経験している私たちのグループの改善につながるでしょう！

すごい！ ここでしばらくして、数分経ったらPRをまとめます。 完了すると、リポジトリでgatsby-dev-cliを使用できるようになり、パッチが公開されるまで開発環境が機能するようになります（ gatsby-dev-cliに慣れていない場合は、助けて）。 私は適切なOSを持っていないので、とにかく変更をテストするためにあなたを募集しようとするかもしれません...同じことがこの問題を経験しているこのスレッドの他のすべての人にも当てはまります。

終わったらここに投稿します。

この症状を引き起こす別の問題を見つけました-https：//github.com/gatsbyjs/gatsby/issues/17935

誰かがLokiJSを使用していて、ターミナルのサイズを変更しても修正されない場合は、私が見つけた問題である可能性が非常に高いです。

やあみんな、 @ ehowey 、PR＃17938をチェックしてください。 誰かがテストする気があるなら、やってください、そしてPRに線を引いてください。

あなたは私のレポを暗礁に、そしてあなたのようにそれを使用することができますgatsby使用して、サイト内のソースgatsby-dev-cli 。 まず、 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日、10：23 AM -0600、ジェレミー・オルブライトで[email protected] 、書きました：

@steinitz、@rheinardkorf、@ hbthen3rd、@sharvit、@JaKXz、@emilyaviva、@MaximeHeckel
＃17938をテストしてくれる人はいますか？
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

これに対する修正に関する更新はありますか？ [Firebase Source] Fetching data for ...試した後、私と私の友人にとってもソースノードと変換ノードでフリーズしています

残念ながら、端末のサイズを変更しても修正されないようです。

@ rishabhaggarwal2同様の問題が発生しているように思われます。オンラインソースからデータを取得しているときに、ハングアップします。 GATSBY_CONCURRENT_DOWNLOAD=10 gatsby developを使ってみてください。

これも見て。 ルーメンの起動時に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開発を（あなたの拡張機能で）再実行することによってそれを引き起こしましたが、ビルドは引き続き機能します。

とは言うものの、これはジェットコースターに乗っているので、問題が再発するのを心から準備しています：smile ：。

明確にするために：これまでのところ、とても良いです。

おっと、更新：これを投稿する前に最終テストのためにWebStormを再起動しましたが、WebStormターミナルのsource and transform nodesでハングしました。

この問題を見つけた他の人は、試してみてください

CHOKIDAR_USEPOLLING=1 gatsby develop

これにより、MacOSでfseventsが無効になります。これは、信頼できる回避策のようです。

@ Js-Brecht ubutu 18.04を使用していますが、同じ問題が発生することがあります。 私のOSについて何か提案はありますか？ この問題の考えられる原因について詳しく教えてください。

これは、@ Js-Brechtと@RomanHotsiyの勤勉な作業のおかげで解決されました。 これはfseventsのアップストリームの問題であり、私が自分で理解できたものをはるかに超えていました。これらの変更が実装され、fseventsからgatsby自体に移行したら、将来のアップデートで修正する必要があります。 今のところ、信頼できる回避策はターミナルウィンドウのサイズを変更することです。これをリポジトリ自体で修正する方法があります。これについては、 https ：

修正がダウンストリームでgatsby自体に移行するまで、問題を開いたままにしておきます。

@ Boty22 Ubuntuはfsevents使用しないので、おそらく何か違うものです。 リモートの場所からデータを取得するときに、いくつかの問題が発生しました。 並行性の問題を修正する方法の詳細については、＃6654と＃17940を確認してください。

簡単な質問：端末のサイズ変更は役に立ちますか？ もしそうなら、それはこの問題に_何か_似ている可能性があります。

@ Js-ブレヒトがターミナルのサイズを変更してもUbuntuには役立ちません。 プラグインgatsby-source-airtableBTWを使用してAirTableテーブルからデータを取得しています

それが問題になる可能性があります。 このコメントをチェックしてください。 それがうまくいかない場合は、新しいチケットを開く方が良いかもしれません

@steinitz申し訳ありませんが、コメントを逃しました。 ＃17938で説明されている修正を試すことができますか？ より具体的には、こことここ。 それが機能しない場合は、おそらくあなたのケースでさらに多くのことが起こっています。

言及されて以来、 CHOKIDAR_USEPOLLING=1 gatsby develop問題はありません。

回避策をありがとう@ Js-Brecht

gatsbyビルドを実行すると、2.15.28でもこれが発生します。 他のターミナルでのギャツビーの開発を停止する必要がありますか？ それは断続的に起こっています

開発サーバーが実行されていない状態で再び発生しました。 でも、ブログのチュートリアルに従うことで簡単なブログを手に入れることができます。

それはほぼすべての他の実行のようです。 私は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/en/docs/selective-version-resolutions/）を使用することです。 あなたに以下を加えることでpackage.json 、次に実行するyarn 、それはまた、推移的依存関係をアップグレードして更新しますyarn.lockファイルを：

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

これを実行してロックファイルを更新したら、 resolutionsプロパティをpackage.json再度削除できます。

編集：以前の誤ったバージョンの指示を削除しました。

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完全に削除しましたが、ローカルとnetlifyの両方が機能しています...

同じ問題が発生し、理由を追跡できませんでした。 これはMacとPCの両方で私に起こります。 これをインターネットの速度に関連付けようとすることもできますが、これは私が高速ネットワークに接続しているときにも起こりました。 今私のために働いているように見えるのは、これを私の環境に追加することです

GATSBY_CONCURRENT_DOWNLOAD=5

--v8-pool-size=128を使用して実行します

私の場合、それはosxのファイアウォールプロンプトのようです。 外部からの接続を許可または拒否するのに十分な速さであれば、問題なく成功します。 問題は、Gatsbyが続行するとプロンプトダイアログが一瞬ポップアップし、消えて、上記の多くのステップの1つにぶら下がることに失敗することです。
オプション：

• ファイアウォールを無効にする（それがない）
• ホワイトリストギャツビー（プロジェクトやアップグレード間で一貫性がない）
• ユーザーがオプションを選択するまでプロンプトで停止する方法を見つける
• localhostへのデフォルトのバインドアドレス（着信接続を受け入れるためのプロンプトは必要ありません）。

@thomasthep開発サーバーのデフォルトのバインドアドレスはすでにlocalhostです。 外部IPアドレス（または0.0.0.0）を使用するように指示しない限り、外部接続をリッスンすることさえありません。 それでも、ブートストラップ/ビルドが完了するまで、開発サーバーは起動しません。 ファイアウォールプロンプトを引き起こしているのがブートストラップである場合、Gatsbyはデフォルトの状態ではインターネットに接続しないため、使用しているプラ​​グインとより関係があります。

一般的に言って、「外部から来る」接続すらあってはなりません。 プラグインが外部ソースから情報を収集している場合でも、接続は外部ソースからではなくローカルホストから発生します。私の経験では、ほとんどのファイアウォールが構成されているため、これは通常、ほとんどのファイアウォールによって「確立された接続」として受け入れられます。発信接続を受け入れるため。

ファイアウォールが接続だけでなくプロセスをブロックするように構成されている場合、これが発生することがわかりました。 その場合、ホワイトリストに登録する必要があるのはノードです。

それがあなたに起こっている理由を本当に理解するために、より多くの情報が必要になるでしょう。 ただし、新しいチケットを開く方がおそらく効果的です。 これは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を使ってみてください。

ありがとう、これは私のためにそれを修正しました。 サードパーティのWebサイトから大量のコンテンツを取得していたため、コンテンツのダウンロードを続けていました。 （97％-これまでのところ非常に近い）