Gatsby: [fsevents bug] Unter "Quell- und Transformationsknoten" / "createPagesStatefully" unter MacOS stecken

Aktualisiert - Ich habe getestet, wie die Datei gatsby-node.js auskommentiert wurde, und der Build wurde einmal fortgesetzt, aber dann habe ich es erneut versucht und dies getan, und es blieb wieder an derselben Stelle hängen.

Gibt es eine Chance, die auf meinen alten Computer zurückzuführen ist? Das 2010 Macbook Pro (aktualisiert auf 8 GB RAM und eine SSD) hat mich noch nicht aufgehalten, aber ich weiß, dass seine Tage begrenzt sind. Dies ist ein Hobby für mich und ich habe kleine Kinder, daher waren die Dollars nicht da, um sie für einen neuen Computer auszugeben, da dieser mit dem aktualisierten Ram und der SSD gut funktioniert hat.

Ich habe versucht, zu gatsby 2.13.52 zurückzukehren, der letzten Version, auf der ich stabil war. Ich habe auch versucht, auf 16.8.6 zurückzugreifen.

Interessanterweise ließ ich es einmal erfolgreich bauen, als ich auf 16.8.6 zurück reagierte, aber nach diesem ersten Mal legte es an derselben Stelle auf, was für mich wirklich seltsam ist.

Ich kann auch selten ohne Grund erkennen, dass es gut funktioniert. Es scheint keinen Reim oder Grund dafür zu geben, wann dies geschieht. Ich habe ein paar Stunden damit verbracht, nach Mustern oder Fehlern zu suchen, die dies verursachen könnten, aber nichts gefunden. Ich habe https://github.com/gatsbyjs/gatsby/issues/6654 überprüft und einige der darin enthaltenen Artikel ohne Erfolg ausprobiert.

Dies ist für mich einer der merkwürdigsten Fehler, auf die ich jemals gestoßen bin, weil sich das Verhalten zu ändern scheint, ohne dass es erkennbare Änderungen im Code gibt. In einigen Fällen hängt der Build an Quell- und Transformationsknoten (60% der Zeit), in einigen Fällen bei Stately Create Pages (20%), in einigen Fällen erfolgreich (20%). Ich habe alle drei Verhaltensweisen anzeigen lassen, ohne eine Codezeile zu ändern.

Ich habe dieses Verhalten auch im Gatsby-Starter-Blog wiederholt, was wirklich seltsam ist. Wieder denke ich, dass dies ein Problem für mich vor Ort ist. Interessanterweise hängt es nur bei createPagesStatefully .

Ich fange jetzt an zu denken, dass es etwas mit einer Bibliothek zu tun hat, die von Homebrew automatisch aktualisiert wurde - welche ich keine Ahnung habe, aber es ist das einzige, an das ich denken kann, das ich nicht getestet habe.

Hier ist eine Liste der Dinge, die ich bisher versucht habe:

• Ändern der Knotenversionen, versucht 12, 10 und 8

• Zurückkehren zu einem früheren Punkt in meinem Commit-Verlauf, der funktioniert hat - es schlägt immer noch fehl.

• Plugins und Bereiche der gatsby-config auskommentieren

• Den Inhalt meiner Datei gatsby-node.js auskommentieren

• Testen Sie es erneut auf Netlify, das immer noch erfolgreich erstellt wurde. Deshalb denke ich, dass es etwas mit meinem Computer zu tun haben muss.

• Löschen Sie die 4 Seiten in meinem Verzeichnis src / pages und fügen Sie eine sehr einfache Datei index.mdx ein

• Löschen aller node_module- und Sperrdateien, Neuinstallation

• Computer neu starten

• Erstellen eines Arbeitsbereichs für frisches Garn mit neuen Klonen des Themas / Starters von Github.

• Testen von Gatsby-Starter-Blog, ähnliches Verhalten, aber es hängt an createPagesStatefully

Hallo,

Ich kann wenig tun, aber bestätigen, dass ich dieses Problem bei einer Reihe von Gatsby-Startern sehe. Und wie Sie hervorheben, entscheidet es sich manchmal nur, zu erstellen oder zu stoppen, entweder an "Quell- und Transformationsknoten" oder an createPagesStatefully zu hängen.

Ziemlich frustrierend und führt zu den empörendsten Versuchen, das Problem zu beheben.

Ich habe dieses Problem nicht gesehen, aber es klingt unangenehm und ich würde gerne den Grund für dieses Verhalten auf Ihrer Seite erfahren.

Vorbereitung
Sie sollten versuchen, den Node-Debugger zu verwenden, um das Problem zu beheben. Eine Aufgabe in Ihrer package.json würde so aussehen. Wenn Sie VSCode verwenden, können Sie "Auto Attach" aktivieren, um den internen Debugger zusammen mit dieser Aufgabe zu verwenden (stellen Sie sicher, dass Sie das interne Terminal für diesen Zweck verwenden).

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

Das Debuggen funktioniert natürlich mit jeder IDE. Stellen Sie nur sicher, dass Sie Ihren Debugger korrekt anhängen.

1. Variante: Minimale Reproduktion
Sie haben createPagesStatefully als Ursache des Problems genannt. Wenn Sie sicher sind, dass dies die Ursache des Problems ist, können Sie möglicherweise ein sehr kleines Projekt erstellen, um es zu reproduzieren. Lassen Sie alle Starter hinter sich, verwenden Sie einfach Gatsby direkt und verwenden Sie createPagesStatefully bis gatsby-node.js mit einigen Beispielen, die die Dinge nachahmen, die Ihre Starter tun. Starten Sie dann gatsby und debuggen Sie es durch Node Inspect.

Auf diese Weise können Sie finden, wo es hängt.

2. Alternative: In Ihrem Projekt / Starter
Sie können natürlich versuchen, das Problem in Ihrem Projekt mit derselben Technik zu debuggen. Aber vielleicht haben Sie mehrere Probleme, die sich stapeln und Ihre Sicht auf die Ursache von Problemen verwischen. Daher würde ich immer versuchen, eine minimale Reproduktion zu erzielen, bevor ich mit dem Debuggen beginne.

Viel Glück.

Also ... ich bin auf ein seltsames Verhalten mit den Sperrdateien gestoßen. Vielleicht könnte mich jemand, der mehr weiß, in die richtige Richtung weisen. Während ich versuchte, zu einem minimal funktionierenden Build zu gelangen, reduzierte ich mich im Grunde auf eine "Hallo Welt" -Gatsby-Installation und es funktionierte immer noch nicht, was wirklich seltsam war.

Noch seltsamer wurde, dass die eigentliche Gatsby-Starter-Hallo-Welt auf meinem Computer funktioniert und gut funktioniert. ABER ... wenn ich die Sperrdatei lösche und Garn dazu bringe, eine neue Sperrdatei neu zu erstellen, schlägt der Build fehl und hängt an den Quell- und Transformationsknoten. Ich könnte meine abgespeckte und minimale Implementierung erstellen, wenn ich die Sperrdatei von "hello-world" kopieren und diese verwenden würde. Meine aktuelle Theorie ist also, dass es in meinen Sperrdateien ein Versionsproblem gibt, das dieses Problem verursacht, aber ich stecke hier fest.

Ich habe auch alle meine Homebrew-Installationen gelöscht und Node, Garn, Git usw. neu installiert, nur um sicherzugehen, dass es dort keine lustigen Geschäfte gab.

Danke @ehowey, dass angesprochen hast ... Ich dachte, ich wäre es nur, weil es ziemlich sporadisch ist (aber in mehr als 50% der ⠙ source and transform nodes festhalte, bedeutet das normalerweise, dass ich mein Terminal töten muss.

Wenn ich etwas finde, werde ich es dich wissen lassen. Und ich werde diesen Thread auch sehen.

@georgiee - danke für die --inspektion info. Ich werde sehen, ob das Debuggen von Knoten mit WebStorm funktioniert.

Ich mag auch Ihre Vorstellung von einer minimalen Reproduktion. Aber das wird einige Zeit dauern, bis ich Gatsby etwas tiefer verstehe.

Derzeit hängt es an "Quell- und Transformationsknoten". Selten schafft es es, Seiten statisch zu erstellen und hängt dort. Ansonsten baut es normal.

Ich habe derzeit das gleiche Problem, nachdem ich ein "Garn-Upgrade" durchgeführt habe, um eine anfällige Abhängigkeit zu beheben. Hier ist mein Setup:

System:
Betriebssystem: macOS 10.15
CPU: (4) x64 Intel (R) Core (TM) i7-7567U CPU bei 3,50 GHz
Shell: 5.7.1 - / bin / zsh
Binärdateien:
Knoten: 12.8.1 - / usr / local / bin / node
Garn: 1.17.3 - / usr / local / bin / Garn
npm: 6.10.3 - / usr / local / bin / npm
Sprachen:
Python: 2.7.16 - / usr / local / bin / python
Browser:
Chrome: 76.0.3809.132
Firefox: 68.0.2
Safari: 13.0
npmPackages:
gatsby: ^ 2.13.42 => 2.14.7
Gatsby-Hintergrundbild: ^ 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-Helm: ^ 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-Typografie: ^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts: ^ 1.1.0 => 1.1.0
Gatsby-Bemerkungsbilder: ^ 3.1.10 => 3.1.19
gatsby-bemerkenswert-relative-images-v2: ^ 0.1.5 => 0.1.5
gatsby-bemerkenswert-responsive-iframe: ^ 2.2.5 => 2.2.10
gatsby-source-filesystem: ^ 2.1.6 => 2.1.18
Gatsby-Transformator-Bemerkung: ^ 2.6.12 => 2.6.19
Gatsby-Transformator-scharf: ^ 2.2.5 => 2.2.12

Ich habe derzeit das gleiche Problem, nachdem ich ein "Garn-Upgrade" durchgeführt habe, um eine anfällige Abhängigkeit zu beheben. Hier ist mein Setup:

Update: Ich kann Probleme beheben, indem ich meine alte "yarn.lock" -Datei wiederherstelle.

@ hbthen3rd

Update: Ich kann Probleme beheben, indem ich meine alte "yarn.lock" -Datei wiederherstelle.

Ich habe die Erfahrung gemacht, dass das Problem ohne klaren Grund verschwinden kann, um später zurückzukehren. Möglicherweise tritt das Problem trotz Wiederherstellung von yarn.lock wieder auf. Halten uns auf dem Laufenden.

Hier ist eine minimale Reproduktion mit Gatsby-Starter-Hallo-Welt:

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

Die aktuelle Sperrdatei, die im Repo enthalten ist, schlägt für mich fehl. Ich habe auch Kopien in das Repo von yarn-working.lock und yarn-notworking.lock . Hoffentlich erleichtert dies jemandem die Fehlerbehebung.

Meine aktuelle Umgebung:

System:
Betriebssystem: macOS High Sierra 10.13.6
CPU: (2) x64 Intel (R) Core (TM) 2 Duo-CPU P8600 bei 2,40 GHz
Shell: 3.2.57 - / bin / bash
Binärdateien:
Knoten: 10.16.3 - / usr / local / bin / node
Garn: 1.17.3 - / usr / local / bin / Garn
npm: 6.10.3 - / usr / local / bin / npm
Sprachen:
Python: 2.7.10 - / usr / bin / python
Browser:
Chrome: 76.0.3809.132
Firefox: 67.0.2
Safari: 12.1.2
npmPackages:
gatsby: ^ 2.13.73 => 2.15.0
npmGlobalPackages:
gatsby-cli: 2.7.40

Ich habe das gleiche Problem.

Eine Richtung, die ich gefunden habe:

1. Das Herabstufen von gatsby-plugin-sitemap von 2.2.9 auf 2.2.6 löste das Problem mit yarn develop .

   • Es ist seltsam, weil gatsby-plugin-sitemap die Entwicklung nicht beeinflussen sollte.

2. yarn build funktioniert immer noch nicht, aber wenn ich gatsby-plugin-sitemap aus meiner Konfiguration entferne, funktioniert yarn build wieder.

@sharvit Ich kann berichten, dass dies in meinem Fall nicht funktioniert hat. Ich bin froh, dass es das Problem für Sie behoben hat. Ich denke, es hat letztendlich etwas mit den Sperrdateien und einem seltsamen Versionsproblem tief im Darm der Sperrdatei zu tun.

Ich habe es meistens geschafft, zu einem funktionierenden Build zurückzukehren, vielleicht 8/10 Mal, indem ich zu einer alten Sperrdatei zurückgekehrt bin und etwas kopiert und eingefügt habe. Ich kann jetzt auch STRG + C drücken, um das Beenden des Builds zu erzwingen, wenn es hängt, was ich an einem Punkt in diesem Prozess nicht tun konnte. Ich weiß nicht, was das Problem in der Sperrdatei behebt, aber ich denke, die Hinweise befinden sich in dem oben veröffentlichten Repository mit zwei Kopien einer Sperrdatei, eine, die funktioniert, und eine, die nicht funktioniert. Dies ist ein seltsames Tier eines Käfers. Normalerweise funktionieren Dinge im Computerland beruhigend oder nicht.

@steinitz Hast du Glück? Ich hatte, was Sie erwähnen, passiert. Es schien besser zu werden, ziemlich gut, aber nicht perfekt und jetzt scheitert es fast jedes Mal wieder. Ziemlich frustrierend.

@ehowey

Wie Sie sich vorstellen können, zögere ich aufgrund der Tatsache, dass dieses Problem immer wieder auftritt, zu berichten. Hier ist ein typisches Beispiel:

Nachdem Sie das Verzeichnis node_modules gelöscht haben, löschen Sie yarn.lock und führen Sie es aus
npx yarn-upgrade-all
und
yarn install
alles war gut.

Dann, gerade jetzt, als Antwort auf Ihre Nachricht, habe ich es versucht
yarn start
Ergebnis: es hängt wieder an
source and transform nodes

Ich nehme an, es gibt zwei sinnvolle Dinge zu tun:

1. Befolgen Sie den Rat von @georgiee, damit das Debugging von Webstorm funktioniert
   node --inspect und sehen, ob ich offensichtliche Probleme erkennen kann
2. Legen Sie Gatsby für eine Weile beiseite, um zu sehen, ob eine kluge Person das Problem löst

Aktualisieren:

ctl-C hat den oben beschriebenen Prozess blockiert (der den festgefahrenen Prozess nicht gestoppt hat, was doppelt ärgerlich war).
Dann blieb yarn start bei createPagesStatefully .
ctl-C würde wieder ein weiteres yarn start - stecken auf source and transform nodes
ctl-C würde noch einmal (zum Teufel) - diesmal hat yarn start funktioniert und es läuft

Ich weiß nicht, was ich davon halten soll, aber da ist es.

Dies ist ähnlich wie das, was ich sehe. Heute Abend scheint es schlimmer zu sein, vielleicht 1/10 mal oder weniger erfolgreich zu bauen. Aus Sicht der Programmierung / Codierung ist dies ein sehr merkwürdiges Verhalten. Anekdotisch schien es vor ein paar Tagen um 2.15.1 besser zu funktionieren als heute um 2.15.6. Ich frage mich auch, welche Gemeinsamkeiten wir alle teilen, die diesen Fehler verursachen. Können Sie den Befehl gatsby info --clipboard ausführen und veröffentlichen?

Es ist offensichtlich nicht sehr verbreitet, sonst würde es eine Flut von Berichten geben, aber es ist auch nicht nur ich, wie ich ursprünglich dachte. Wir alle scheinen auch Garn zu verwenden, was für mich eine Voraussetzung ist, wenn ich an Themen in einem Garnarbeitsbereich arbeite. Ich bin immer noch in der Lage, dies auf der Gatsby-Starter-Hallo-Welt zu reproduzieren, daher glaube ich, dass es sich um ein Abhängigkeitsproblem oder einen Konflikt in den Kern-Gatsby-Dateien handelt.

@ehowey hier ist das gatsby info Sie angefordert haben

System:
Betriebssystem: macOS 10.14.6
CPU: (4) x64 Intel (R) Core (TM) i7-5557U CPU bei 3,10 GHz
Shell: 3.2.57 - / bin / bash
Binärdateien:
Knoten: 12.9.1 - / usr / local / bin / node
Garn: 1.17.3 - / usr / local / bin / Garn
npm: 6.11.2 - / usr / local / bin / npm
Sprachen:
Python: 2.7.16 - / usr / local / bin / python
Browser:
Chrome: 76.0.3809.132
Firefox: 68.0.1
Safari: 12.1.2
npmPackages:
gatsby: ^ 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-Helm: ^ 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-Bemerkungsbilder: ^ 3.1.19 => 3.1.19
gatsby-bemerkenswert-prismjs: ^ 3.3.9 => 3.3.9
gatsby-source-filesystem: ^ 2.1.18 => 2.1.18
Gatsby-Transformator-Bemerkung: ^ 2.6.19 => 2.6.19
Gatsby-Transformator-scharf: ^ 2.2.12 => 2.2.12
npmGlobalPackages:
gatsby-cli: 2.7.40

Ich hatte das gleiche Problem: Die Site wurde fehlerfrei auf Netlify erstellt, blieb aber mit gatsby build und gatsby develop auf meinem Entwicklungscomputer hängen.

Nachdem ich mit Paketversionen herumgespielt hatte, bemerkte ich, dass das Zurücksetzen von gatsby-plugin-sitemap von Version 2.2.10 auf 2.2.9 das Problem für mich behoben hat. Seltsamerweise scheinen einige Leute hier Probleme mit 2.2.9 zu haben, was bedeuten könnte, dass das Problem woanders liegt.

Bearbeiten: Gatsby hat zu früh gesprochen und hängt immer noch an den Schritten "Quell- und Transformationsknoten" und "createPagesStatefully", wenn auch viel seltener.

@goblindegook Dies scheint ein häufiges Muster bei diesem speziellen Problem zu sein. Weil das Problem kommt und geht, scheinbar mit dem Wetter, der Tageszeit, der Zeit seit dem Hochfahren ... Sie können glauben, dass etwas, das Sie getan haben, es behoben hat - nur um es erneut auftreten zu lassen.

Auch bei diesem Problem wurde gatsby-plugin-sitemap auf 2.2.6 herabgestuft, und das scheint es behoben zu haben

FWIW, ich erlebe dies auch, benutze aber weder yarn noch gatsby-plugin-sitemap .

Mein gatsby info für den Fall, dass es hilft:

  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

Für mich hat das Bereinigen des Caches mit gatsby clean das Problem gelöst.

Ich mache immer noch Jagd und versuche das herauszufinden. Immer noch ein Problem für mich. Weiß jemand, ob dies mit dem Wechsel von babel 7.0.0 -> 7.5.5 zusammenhängt? Dieser Wechsel erfolgte ungefähr zu der Zeit, als ich anfing, diesen Fehler zu erleben, und fiel damit zusammen, dass ich anfing, Probleme zu sehen ... Ich habe versucht, Garnauflösungen zum Laufen zu bringen, um die Babel-Versionen auf 7.0.0 zu fixieren, hatte aber keinen Erfolg damit das noch.

Ich denke, ich kann einen Einblick geben - ich bekam dieses Problem, als ich nach der Hälfte des Hinzufügens von Plugins zu einem Projekt gatsby-cli in einem anderen Terminalfenster aktualisierte. Das Ausführen von gatsby clean in meinem Projekt hat funktioniert.

von https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 - Ich sehe dieses Problem ebenfalls, aber gatsby clean hat es nicht gelöst. Es scheint, als ob nur der CLI-Ausdruck hängen bleibt, weshalb die Größenänderung des Terminals das Problem behebt. 🤷‍♂ 😕 ❓❗️

Das Ändern der Größe des Terminalfensters scheint es für mich zu beheben! Ich habe es nicht sehr ausführlich getestet. Können einige andere Leute, die dieses Problem haben, dies auch versuchen? Was für ein seltsamer Fehler und eine möglicherweise seltsame Lösung.

Ich habe genau das gleiche Problem: Gatsby bleibt häufig auf "Quell- und Transformationsknoten" oder "createPagesStatefully" hängen, und ich verwende keine Quell-Plugins. Ich bin erst kürzlich auf den Fix "Terminalfenster ändern" gestoßen und bin zu 140% verblüfft darüber, wie zum Teufel dies das Problem behebt, aber es funktioniert. Dies scheint ein ziemlich ernstes Problem zu sein!

@JaKXz - Danke! Das hat mich verrückt gemacht. Das Update scheint die Größe des Terminalfensters in VS Code zu ändern. Ziehen Sie es einfach ein wenig nach oben oder unten und die Entwicklungsaufgabe tuckert glücklich mit. Ich habe in verschiedenen Fällen sowohl Garn als auch Npm, Arbeitsbereiche und nicht getestet. Schien in all diesen Fällen für mich zu arbeiten. Es scheint auch für mich jetzt öfter einzufrieren oder bei createPagesStatefully hängen als source and transform nodes . Ich werde das Problem vorerst offen lassen. Möglicherweise muss dies von jemandem mit mehr Know-how als mir auf eine weniger "hackige" Weise behoben werden.

@ehowey Ich habe das gleiche Problem und das Verschieben des Terminalfensters in vscode funktioniert (konnte es nicht glauben, als ich dieses Problem las, bis ich es selbst versuchte).
Wissen Sie, ob dies nur bei VS Code der Fall ist?

Ich habe dieses Problem auf iTerm 2, daher ist es nicht VS-Code-spezifisch.

Mein Problem war auch in iTerm 2

Webstorm-Terminal, Mac-Terminal, iTerm

Hat die Größenänderung des Terminals für Sie alle in verschiedenen Entwicklungsumgebungen funktioniert?

Meiner Meinung nach funktionierte die Größenänderung des Terminals unter iTerm und VSCode (es dauerte einige Versuche, das Problem auf iTerm zu reproduzieren).

Der Trick zum Ändern der Terminalgröße funktioniert in iTerm 2 zuverlässig für mich.

Ja, die Größenänderung von iTerm 2 funktioniert einwandfrei

Wenn die Größenänderung funktioniert, vermute ich, dass dieser Fehler mit dem Puffer zusammenhängt und irgendwo eine Standardspülung benötigt.

Diese Art von scheint ein Problem mit Kernel + Shell zu sein. Wahrscheinlich interagiert der Knoten auf irgendeine Weise mit Ihrem Kernel und / oder Ihrer Shell. Ich sage das nur, weil ich die Probleme scheinbar nicht unter Linux oder Windows replizieren kann. Ich kann anscheinend keine bekannten Probleme finden. Entweder a) es handelt sich um eine Kombination von Codemustern, die nur für Gatsby + die Interaktion mit dem System gelten, oder b) ich kenne nur noch nicht die richtige Frage.

Wenn die Größenänderung des Terminals das Problem behebt, liegt möglicherweise ein Fehler zwischen dem Knoten und kqueue , der einen Block in der Ereignisschleife verursacht. Durch Ändern der Größe des Terminals wird dem Prozess ein SIGWINCH-Signal gesendet, das die Ereignisschleife unterbricht, sie freigibt und die Fortsetzung ermöglicht.

Können Sie versuchen, kill -SIGWINCH ${pid} für den laufenden Prozess auszuführen, wenn dieser einfriert? Sollte genauso funktionieren wie die Größenänderung des Terminals.

Ich bin auch daran interessiert, ob dies in allen Muscheln passiert oder nicht. Basierend auf den bisherigen Informationen ist dies in bash und zsh fehlgeschlagen, und dies ist wahrscheinlich einer der gemeinsamen Faktoren aller Terminalemulatoren. Könnt ihr einen oder mehrere von sh , csh , ksh , tcsh usw. ausprobieren?

Wenn das Problem in allen Shells auftritt, würde ich vermuten, dass der Kernel die Ereignisschleife des Knotens auf diese Weise behandelt. Dies könnte auch der Grund sein, warum es sich um ein zeitweiliges Problem handelt. Wenn eine Funktion weniger Prozessorzeit erhält (möglicherweise aufgrund der variablen Systemlast), wird sie möglicherweise zu lange blockiert, und der Kernel versucht möglicherweise, einen Ereignisknoten irgendwo wiederzuverwenden, was zu einem Deadlock führt. Ich bin mit den Interna der API nicht besonders vertraut, aber ich wette, dass source and transform nodes ziemlich dateisystemintensiv ist. Das bedeutet, dass wahrscheinlich viel Abladen stattfindet. Wer weiß also, was auf niedrigeren Ebenen wirklich passiert?

Ich denke, es wäre eine gute Idee, die Oberfläche dieses Fehlers einzugrenzen. Es kommt am häufigsten in source and transform nodes , wie es aussieht. Versuchen Sie also, es auf das zu blockierende Plugin einzugrenzen. Versuchen Sie, node_modules/gatsby/dist/utils/api-runner-node.js die folgenden Zeilen hinzuzufügen:

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

Führen Sie dann node inspect node_modules/.bin/gatsby develop . Es wird brechen, sobald es beginnt, also müssen Sie c debug> drücken, wenn Sie zur Eingabeaufforderung debugger -Linie exec console.log(plugin) und notieren Sie, was in resolve . Drücken Sie dann c um fortzufahren. Tun Sie dies einfach, bis es hängt ... wenn es hängt.

Aufgrund der Art der Ereignisschleife wette ich, dass sie beim Debuggen nicht einmal hängen bleibt. Diese Interrupts reichen wahrscheinlich aus, um die Spur zu halten. Asynchrone Fehler können ein echtes Problem sein. Wenn es während der Verwendung des Debuggers nicht hängen bleibt, ersetzen Sie diese Zeile debugger durch:

reporter.log(plugin.resolve);

Hoffentlich taucht das etwas auf. Es wäre schön zu sehen, welches Plugin den Block verursacht. Wenn wir das herausfinden können, können wir möglicherweise herausfinden, was optimiert / überarbeitet werden muss, um dies zu klären.

Die Größenänderung funktioniert auch für mich. Ich verwende zsh als meine VSCode-Shell.

@ Js-Brecht - Vielen Dank, dass Sie sich die Zeit für eine so detaillierte Antwort genommen haben. Ich war mir nicht sicher, wo ich kill -SIGWINCH ${pid} . Ich konnte es während des Erstellungsprozesses nicht tun.

Mit dem Debugger kam der folgende Code heraus ... über mich hinaus, um viel Sinn daraus zu machen. Ich steckte tatsächlich im Debugger fest, aber .exit funktionierte immer noch.

⠋ 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 hat mit Terminal die Größenänderung für mich funktioniert.

@ehowey Nur damit ich weiß, dass ich dich richtig verstehe, hat es gatsby-source-filesystem der Schuldige ist, was für mich Sinn macht ... insbesondere aufgrund bestehender, verwandter Gatsby-Probleme.

Ich würde gerne sehen, ob das Plugin einen Testlauf verarbeiten kann. Wenn es beim Ausführen von Tests hängt, ist dies meiner Meinung nach eine einfache Möglichkeit, um festzustellen, wo es fehlschlägt. Wenn nicht, muss ich nur etwas sezieren / debuggen, was für mich schwierig sein wird, da ich kein MacOS habe.

Können Sie das Haupt-Gatsby-Repo herunterladen und die gatsby-source-filesystem -Tests ausführen?

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

Tun Sie dies alles auch mit Ihrem Repository für minimale Reproduktion? Ich sehe, dass gatsby-plugin-mdx zweimal ausgeführt wurde, was mir sagt, dass es kein Barebone-Repository ist. In einer perfekten Welt sollte es keine Rolle spielen, aber ich denke, es wäre besser, ein möglichst einfaches Setup durchzuführen. Wenn Sie es mit dem minimalen Repo nicht zuverlässig zum Scheitern bringen können, verwenden Sie dasjenige, das am konsequentesten ausfällt (jedes Mal (oder in der Nähe von) am selben Ort).

😉

kill -SIGWINCH ${pid} muss von einer anderen Shell-Instanz ausgeführt werden. Wenn der Build hängt, öffnen Sie ein anderes Terminalfenster / eine andere Registerkarte und führen Sie den Befehl von dort aus. Dieser kleine Ausschnitt sollte funktionieren:

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 }')

Wenn Fehler auftreten, führen Sie die Befehle separat aus:

# 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

Wenn Sie nach dem Ausführen der Tests mit leeren Händen auftauchen, ist es meiner Meinung nach nützlich, einen Core-Dump zu haben, damit wir einen Stack-Trace erhalten können. Aber Schritt für Schritt.

@ Js-Brecht Entschuldigung für die langsameren Antworten ... das ist wirklich nur ein Nebenhobby, das ich abends in der Freizeit mache.

Also habe ich das Gleiche im Gatsby-Hallo-Weltstarter ausgeführt - so nackt wie möglich. Es tut mir leid, dass ich es zuvor in meinem Hauptarbeitsbereich für ein Projekt ausgeführt habe, mit dem ich Probleme hatte. Ich habe es zuvor auf Startern repliziert, daher glaube ich nicht, dass es sich um ein Plugin handelt, sondern um etwas im Kern von Gatsby.

Es hängt an Quell- und Transformationsknoten und gibt mir die folgende Ausgabe:

< 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

Hier ist ein Speicherauszug aus dem Befehl gatsby info, falls dies hilfreich ist:

  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

Als Randnotiz: Wenn ich Ihren Debug-Befehl verwende, hängt er an Quell- und Transformationsknoten. Wenn ich Gatsby Develop verwende, hängt es für mich jetzt meistens bei createPagesStatefully. Tut mir leid, dass ich weiß, dass dies wirklich seltsam ist. Um ehrlich zu sein, bin ich mir nicht sicher, wie viel Arbeit es von Ihrem Ende der Dinge wert ist. Die Größenänderung des Terminalfenster-Tricks funktioniert jedes Mal für mich und andere. Es ist eine hackige Lösung, aber es darf nicht so viele Benutzer betreffen, sonst würden die Probleme überflutet.

Dies hat auch hier begonnen. Der Trick "Größe des Terminals ändern" löst ihn auf. sehr komisch!

+1 Funktioniert nicht in iTerm2, sondern im Terminal 🤷‍♂️

@ehowey Der Großteil dessen, was während des

Kann ich Sie dazu bringen, diese Zeilen zu ändern?

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

Führen Sie dies aus und kopieren Sie die gesamte Ausgabe (fügen Sie sie möglicherweise sogar als .txt -Datei an Ihre Antwort an). Es wird wesentlich ausführlicher sein, und viele Informationen werden wahrscheinlich unnötig sein, aber 🤷‍♂.

Nachdem Sie dies getan haben, möchte ich sehen, ob das Erhöhen des Thread-Pools des Knotens einen Unterschied macht. Ich habe andere Probleme bemerkt, die dieselben oder ähnliche Probleme erwähnen. Meistens kommen sie in source and transform , und einige reden davon, dass diese Phase ewig dauert oder völlig abgeschlossen ist. Ich möchte also sehen, ob es sich um einen Deadlock im Dateisystem handelt. Der asynchrone Dateisystemzugriff wird vom Knoten auf verschiedene Threads verlagert, und der Knoten verfügt standardmäßig nur über einen Pool von 4 Threads für den Benutzerbereich. Wenn diese gefüllt sind und weitere Auslagerungen erforderlich sind, werden die Aufgaben in der Hauptereignisschleife in die Warteschlange gestellt und warten auf einen Thread. Dies könnte möglicherweise das gesamte Programm zum Stillstand bringen ... bis ein Thread verfügbar wird. Gatsby verwaltet einen Cache im Dateisystem. Vielleicht tritt irgendwo eine Kollision auf, und wenn ein Deadlock auftritt, warten die Threads möglicherweise auf eine Zeitüberschreitung / Unterbrechung, bevor sie fortfahren, und wenn es Dutzende (oder sogar Hunderte) gibt. Bei Dateisystemzugriffsereignissen könnten alle auf dasselbe Zeitlimit warten und dazu führen, dass sich alles stapelt. Sie können sehen, dass die Wartezeiten dadurch sehr schnell ansteigen können.

Das Erhöhen der Poolgröße kann dazu beitragen, einen Teil des Datenverkehrs zu verringern ... oder es kann genauso geschehen, nur mit mehr Threads 😆.
Versuchen Sie den folgenden Befehl:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht Das Ändern der Thread-Pool-Größe schien keinen großen Unterschied zu machen.
Ich erhalte die folgende Ausgabe vom Standardbefehl gatsby develop mit den oben genannten Änderungen. Immer noch auf dem grundlegenden Hallo-Welt-Gatsby-Starter.

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

Dies ist ein Beispiel, in dem es an createPagesStatefully hängt. Ich habe es geschafft, den Build fortzusetzen, indem ich die Größe des Terminalfensters geändert habe. Was ist internal-data-bridge eine Chance, die in irgendeiner Weise der Schuldige sein könnte? Das war in beiden Befehlen enthalten, die Sie mich bisher gebeten haben, auszuführen.

Können Sie zeigen, an welcher Linie es hing?

createPagesStatefully dev-404-page

Ich bin nicht 100% sicher, ob der Teil dev-404-page noch vorhanden war, aber er hing an der ersten Instanz von createPagesStatefully

Vielen Dank. Ich würde jetzt gerne weitere Änderungen ausprobieren, wenn Sie nichts dagegen haben.

Bitte aktualisieren Sie die angegebenen Zeilen in den folgenden Dateien:

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 => {

Ich habe den Verdacht, dass hier chokidar schuld sein könnte. Es wurde vor ungefähr einem Monat auf v3.x aktualisiert und es sieht so aus, als hätten sie entweder angefangen, fsevents , oder sie haben etwas getan, das ein fehlerhaftes Verhalten in Bezug auf fsevents . Sie haben einige offene Probleme, die denen ähneln, mit denen wir hier konfrontiert sind, wobei der Knoten hängt, wenn chokidar.watch() . Dies scheint zu passen, da es auf MacOS lokalisiert ist, da fsevents ein Mac-Prozess ist und der Build in den Modulen, in denen er verwendet wird, oder in Modulen, die Dateien schreiben / verarbeiten, fehlschlägt das werden wahrscheinlich beobachtet.

chokidar.watch() existiert auch in gatsby-source-filesystem , und dort ist es mit Ihrem anderen Repo fehlgeschlagen, @ehowey; Ganz zu schweigen davon, dass gatsby-source-filesystem in Ihrem Minimal-Repo nicht aufgerufen wird. Dies erklärt, warum es über source and transform . Es gibt Fälle von chokidar vor internal-data-bridge , aber ich denke an Orten, die den Build nicht beeinflussen (z. B. query-watcher ). Ich glaube jedoch, dass internal-data-bridge der Grund ist, warum es beim Ausführen des Debuggers hängen geblieben ist. und in einem direkten Durchlauf hatte dies wahrscheinlich Auswirkungen auf spätere Phasen des Baus.

Lassen Sie mich wissen, ob dies die Probleme behebt oder ob es weiter geht als bisher. :gekreuzte Finger:

@ Js-Brecht Du kommst irgendwohin! Ich habe gatsby develop wahrscheinlich 15 Mal ausgeführt. Es hing nie an source and transform nodes oder createPagesStatefully aber es schien, vielleicht 2/10 Mal, an start webpack server zu hängen. Ich könnte dies zusammen mit dem Trick der Größenänderung des Terminals auch stoßen. Gibt es eine Chance, dass Sie eine Instanz von Chokidar / Fsevents verpasst haben, die sich auf start webpack server beziehen würde?

Als Randnotiz schien es auch viel schneller als zuvor durch die Schritte des Entwicklungsprozesses zu gehen, wenn das etwas damit zu tun hat?

Das ist wirklich gut zu hören. Ich habe absichtlich eine Instanz von Chokidar verlassen, und diese befindet sich direkt nach Abschluss des Bootstraps und Starten des Servers. Es befindet sich gegen Ende der startServer() -Funktion in node_modules/gatsby/dist/commands/develop.js . Ich bin gerade nicht an einem Computer, oder ich würde Ihnen einen Unterschied machen.

Sie finden die genaue Zeile, indem Sie Folgendes tun:

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

Ich war mir ziemlich sicher, dass wenn dies den Bootstrap reparieren würde, er immer noch am Server hängen müsste. Lassen Sie mich wissen, ob Änderungen dazu führen, dass sie zuverlässig funktionieren, und ich werde eine PR einreichen und mich darum kümmern, die Leute darüber zu informieren.

Ich bin eigentlich nicht überrascht, dass es dadurch schneller läuft. Der Build auf einem Barebone - Projekt in der Regel nimmt mich vielleicht ein zweiten, und ich sah ein paar verrückten lange Laufzeiten für bestimmte Phasen in Ihrer Debug - Ausgabe. fsevents soll die Dinge beschleunigen und die CPU stark entlasten, aber es ist etwas Komisches los, das sie stattdessen stecken lässt.

@ Js-Brecht Mein Hut geht an dich. Ich habe keine Ahnung, wie Sie dieses Kaninchen aus einem Hut gezogen und einen so seltsamen Fehler aus der Ferne behoben haben, aber gute Arbeit! Ich werde warten, bis der Diff Änderungen an develop.js vornimmt, da ich nicht das Falsche ändern möchte, aber ich vermute, dass dies das Problem beheben wird, da es beim allerletzten Schritt hängen geblieben ist, als es den Server ein paar Mal startet von Zeiten.

Hier ist der Unterschied:

node_modules/gatsby/dist/commands/develop.js

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

Ich bin sehr dankbar für Ihre Hilfe bei all diesen Tests. Dies war eine knifflige Angelegenheit, aber es war eine Gelegenheit, sich mit den Interna von MacOS vertraut zu machen, und ich lerne immer gerne neue Dinge: leicht_smiling_face:

Bitte lassen Sie mich wissen, wie es geht; noch nicht ganz aus dem wald: sweat_ smile:.

Funktioniert! Ich bin gerade gatsby develop 10+ Mal gelaufen und es hat einwandfrei funktioniert. Vielen Dank für Ihre Hilfe bei der Prüfung. Hoffentlich verbessert sich dies für die Gruppe von uns, die dies erlebt!

Großartig! Hier werde ich in Kürze, wenn ich ein paar Minuten Zeit habe, eine PR zusammenstellen. Sobald dies erledigt ist, können Sie gatsby-dev-cli mit meinem Repo verwenden, sodass Sie eine funktionierende Entwicklungsumgebung haben, bis ein Patch veröffentlicht wird (wenn Sie mit gatsby-dev-cli nicht vertraut sind, kann ich das Hilfe). Ich könnte versuchen, Sie zu rekrutieren, um die Änderungen trotzdem zu testen, da ich nicht das richtige Betriebssystem habe. Gleiches gilt für alle anderen in diesem Thread, bei denen dieses Problem auftritt.

Ich werde hier zurück posten, wenn es fertig ist.

Ich habe ein anderes separates Problem gefunden, das ebenfalls dieses Symptom verursacht - https://github.com/gatsbyjs/gatsby/issues/17935

Wenn jemand LokiJS verwendet und die Größe des Terminals nicht behebt, ist dies wahrscheinlich das Problem, das ich gefunden habe.

Hey Leute, @ehowey , bitte schaut euch PR # 17938 an. Wenn jemand bereit ist zu testen, tun Sie dies bitte und schreiben Sie eine Zeile in die PR.

Sie können sich mein Repo schnappen und es als gatsby Quelle auf Ihrer Website verwenden, indem Sie gatsby-dev-cli . Zuerst benötigen Sie gatsby-dev-cli

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

Dann klonen Sie einfach das Repo und booten es.

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}"

Gehen Sie dann zu der Site, in der Sie das Repo verwenden möchten, und führen Sie gatsby-dev

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

In meinem Fall, in dem ich OSX und IntelliJ verwende, musste ich:

• Schließen Sie das Projekt in IntelliJ
• Versuchen Sie es erneut ( npm start )
• und öffnen Sie das Projekt in Intellij erneut
  Ich denke, dass das Problem mit IntelliJ-Indizierungsdateien zusammenhängt

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

Ist einer von euch bereit, # 17938 zu testen?

Ich sollte später heute Abend einen Blick darauf werfen können, wenn ich zu Hause bin. Vielen Dank für all Ihre Arbeit daran!
Am 1. Oktober 2019, 10:23 Uhr -0600, schrieb Jeremy Albright [email protected] :

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel
Ist einer von euch bereit, # 17938 zu testen?
- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Irgendwelche Updates zum Fix dafür? Es friert an der Quelle ein und transformiert Knoten für mich und meinen Freund, nachdem es [Firebase Source] Fetching data for ... ausprobiert hat

Die Größenänderung des Terminals scheint dies leider nicht für uns zu beheben

@ rishabhaggarwal2 Es gibt ein ähnliches Problem, das so klingt, als ob es das ist, was Sie erleben, wo es beim Abrufen von Daten aus einer Online-Quelle hängen bleibt. Können Sie versuchen, GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Das auch sehen. gatsby develop beim Lumen-Start überhaupt nicht lokal ausgeführt werden. Hält an createPageStatefully oder source and transform nodes

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

Versuchen Sie es mit allen anderen, die dieses Problem finden

CHOKIDAR_USEPOLLING=1 gatsby develop

Das sollte fsevents unter MacOS deaktivieren, was eine zuverlässige Problemumgehung zu sein scheint.

@ Js-Brecht Ich bestätige, dass es scheint, es dauerhafter zu beheben als die anderen hier erwähnten Problemumgehungen. Danke für das Teilen.

@steinitz du sagst dauerhaft "mehr". Wollen Sie damit sagen, dass es immer noch passiert, wenn Sie diesen Schalter verwenden?

@ Js-Brecht Nein, tut mir leid, unklar zu sein.

Ich spielte auf die Tatsache an, dass andere Problemumgehungen, einschließlich meiner eigenen, eine Weile zu funktionieren schienen, aber das Problem kehrte zurück. Mit Ihrer Lösung habe ich sie provoziert, indem ich Änderungen vorgenommen und Gatsby Develop (mit Ihrer Verbesserung) erneut ausgeführt habe, aber der Build funktioniert weiterhin.

Das heißt, dies war eine Achterbahnfahrt, also bleibe ich emotional vorbereitet: Lächeln: Damit das Problem zurückkehrt.

Um es klar zu sagen: so weit, so gut.

Hoppla, Update: Ich habe WebStorm für einen abschließenden Test neu gestartet, bevor ich dies gepostet habe, und jetzt hängt es an source and transform nodes im WebStorm-Terminal.

Versuchen Sie es mit allen anderen, die dieses Problem finden

CHOKIDAR_USEPOLLING=1 gatsby develop

Das sollte fsevents unter MacOS deaktivieren, was eine zuverlässige Problemumgehung zu sein scheint.

@ Js-Brecht Ich benutze Ubutu 18.04 und stoße gelegentlich auf das gleiche Problem. Gibt es einen Vorschlag für mein Betriebssystem? Würden Sie einige Details zu den möglichen Ursachen für dieses Problem angeben?

Dies wurde dank der sorgfältigen Arbeit von @ Js-Brecht und @RomanHotsiy gelöst. Es war ein Upstream-Problem in fsevents, weit über das hinaus, was ich selbst hätte herausfinden können, und sollte in zukünftigen Updates behoben werden, sobald diese Änderungen implementiert sind und von fsevents nach gatsby selbst migriert werden. Im Moment besteht eine zuverlässige Problemumgehung darin, die Größe des Terminalfensters zu ändern. Es gibt eine Möglichkeit, dies in Ihrem Repo selbst zu beheben, die hier beschrieben wird: https://github.com/gatsbyjs/gatsby/pull/17938. Sie müssten dies jedoch wiederholen Korrektur nach Änderungen an Ihrem Ordner "node_modules" und möglicherweise nicht die Arbeit wert, je nachdem, wie oft Sie Ihre Paketversionen aktualisieren.

Ich werde das Problem offen lassen, bis der Fix stromabwärts in Gatsby selbst migriert wird.

@ Boty22 Ubuntu verwendet nicht fsevents , also ist es wahrscheinlich etwas anderes. Beim Abrufen von Daten von einem Remotestandort sind einige Probleme aufgetreten. In # 6654 und # 17940 finden Sie einige Details zum Beheben von Parallelitätsproblemen.

Kurze Frage: Hilft die Größenänderung Ihres Terminals? Wenn ja, dann könnte es etwas Ähnliches wie dieses Problem sein.

@ Js-Brecht Größenänderung des Terminals hilft für Ubuntu nicht. Ich rufe Daten aus einer AirTable-Tabelle mit dem Plugin gatsby-source-airtable BTW ab

Das könnte das Problem sein. Schauen Sie sich diesen Kommentar an . Wenn das nicht funktioniert, ist es möglicherweise besser, ein neues Ticket zu öffnen

@steinitz sorry, ich habe deinen Kommentar verpasst. Können Sie das in # 17938 beschriebene Update ausprobieren? Genauer gesagt hier und hier . Wenn es nicht funktioniert, ist in Ihrem Fall wahrscheinlich mehr los.

Habe seitdem keine Probleme mit CHOKIDAR_USEPOLLING=1 gatsby develop gehabt.

Vielen Dank für die Problemumgehung @ Js-Brecht

Ich sehe dies auch mit 2.15.28, wenn ich Gatsby Build mache. Muss ich die Entwicklung des Gatsby im anderen Terminal stoppen? Es passiert zeitweise

Wieder passiert, ohne dass der Dev-Server ausgeführt wurde. Ich habe ein einfaches Blog, wenn ich dem Blog-Tutorial folge.

Es scheint fast jeder zweite Lauf zu sein. Ich bin übrigens auf einem Mac

@canvaspixels hat die Größenänderung des Terminalfensters Ihren Build https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991 geholfen hat

@ RomanHotsiy das sortiert es in der Tat! Vielen Dank!

Hallo allerseits, die gepatchte Version von fsevents wurde veröffentlicht. Sie sollten in der Lage sein, einfach Ihre Datei yarn.lock zu löschen und das Garn erneut auszuführen. Jede Ihrer Abhängigkeiten sollte automatisch [email protected] , wodurch das Problem behoben werden sollte.

Seien Sie vorsichtig - das Löschen Ihrer gesamten yarn.lock -Datei kann auch dazu führen, dass andere Pakete aktualisiert werden.

Eine andere, präzisere Option, wenn Sie yarn besteht darin, nur die Zeilen zu löschen, die sich auf fsevents in yarn.lock beziehen, und yarn erneut auszuführen. Dadurch wird nur das betroffene Paket aktualisiert. So habe ich beispielsweise die folgenden Zeilen entfernt:

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

Eine andere Möglichkeit, dies zu tun, besteht darin, die resolutions -Funktion von Yarn (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/) zu verwenden. Wenn Sie Folgendes zu Ihrem package.json hinzufügen und dann yarn , werden auch die transitiven Abhängigkeiten aktualisiert und Ihre yarn.lock -Datei aktualisiert:

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

Nachdem Sie dies getan und Ihre Sperrdatei aktualisiert haben, können Sie die Eigenschaft resolutions aus package.json entfernen.

Bearbeiten: Vorherige, falsche Version der Anweisungen entfernt.

Sie können auch yarn upgrade chokidar@latest ausführen. Das sollte die Sperrdatei mit der richtigen Version von fsevents neu erstellen, ohne etwas anderes zu berühren

Oh, Moment mal. Das ist nur, wenn Sie Chokidar als direkte Abhängigkeit haben 🙄. Vergessen. @ Karlhorky ist richtig

Ich benutze npm . Das Löschen von node_modules , das Ausführen von npm i --save [email protected] und dann npm i hat den Trick für mich getan. Der Start dauerte 19 Sekunden und ich verwende die gatsby-lumen-starter als Basis.

- Bearbeiten:

Ich beendete tatsächlich das, woran ich arbeitete, schob es auf Netlify und es konnte wegen fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ) überhaupt nicht erstellt werden.

Ich bin zu yarn gewechselt und hatte das gleiche Problem, also habe ich fsevents vollständig entfernt, und jetzt funktionieren sowohl local als auch netlify ...

Habe das gleiche Problem und konnte den Grund nicht verfolgen. Das passiert mir sowohl auf dem Mac als auch auf dem PC. Könnte versuchen, dies mit der Internetgeschwindigkeit in Beziehung zu setzen, aber dies passierte mir auch, als ich mit einem Hochgeschwindigkeitsnetzwerk verbunden war. Was momentan für mich zu funktionieren scheint, ist, dies in meine Umgebung aufzunehmen

GATSBY_CONCURRENT_DOWNLOAD=5

und Laufen mit --v8-pool-size=128

In meinem Fall scheint es meine Firewall-Eingabeaufforderung auf osx zu sein. Wenn ich schnell genug bin, um Verbindungen von außen zuzulassen oder zu verweigern, wird dies einwandfrei gelingen. Das Problem ist, dass der Eingabeaufforderungsdialog für den Bruchteil einer Sekunde angezeigt wird und verschwindet, wenn Gatsby fortfährt und dann nicht an einem der vielen oben genannten Schritte festhält.
Optionen:

• Firewall deaktivieren (ohne das)
• Whitelist Gatsby (nicht konsistent über Projekte und Upgrades)
• Suchen Sie nach einer Möglichkeit, die Eingabeaufforderung anzuhalten, bis der Benutzer die Option auswählt
• Standardbindungsadresse an localhost (sollte keine Aufforderung zum Akzeptieren eingehender Verbindungen erfordern).

@thomasthep Die Standardbindungsadresse für den

Es sollte im Allgemeinen nicht einmal Verbindungen geben, die "von außen" kommen. Selbst wenn ein Plugin Informationen von einer externen Quelle sammelt, stammt die Verbindung von Ihrem lokalen Host, nicht von der externen Quelle, und dies wird meiner Erfahrung nach von den meisten Firewalls als "hergestellte Verbindung" akzeptiert, da die meisten Firewalls konfiguriert sind ausgehende Verbindungen zu akzeptieren.

Ich könnte dies sehen, wenn Ihre Firewall so konfiguriert ist, dass sie Prozesse blockiert und nicht nur Verbindungen. In diesem Fall müsste der Knoten in die Whitelist aufgenommen werden.

Benötigen Sie weitere Informationen, um wirklich zu verstehen, warum Ihnen das passiert. Es wäre jedoch wahrscheinlich effektiver, ein neues Ticket zu eröffnen. Dieser hatte mit fsevents unter MacOS zu tun, was zu Problemen führte, und das wurde behoben, weshalb es jetzt geschlossen ist. Alles, was nicht mit fsevents sollte wirklich ein eigenes Problem haben, um die Aufmerksamkeit zu erhalten, die es verdient.

Für den Datensatz kann dies auch passieren, wenn Ihr GraphQL-Server im Debug-Modus ausgeführt wird und er an einem Haltepunkt gestoppt ist.

Für die Aufzeichnung: Dies passierte mir, als ich gatsby-source-s3-image hinzufügte und der s3-Bucket über 100 Bilder erreichte. Es durchläuft alle 145 Bilder auf der source and transform nodes -Stufe und hängt dann für immer dort. Es passiert immer noch, ich habe die obigen Korrekturen ausprobiert. Zum Glück funktioniert es nach 5-6 Versuchen, so dass ich nicht blockiert bin.

Die seltsame Größenänderung des Terminalfensters hat bei mir funktioniert

Für mich scheint es hilfreich zu sein, gleichzeitige Downloads wie hier beschrieben einzuschränken.

Ich habe meiner .env-Datei die folgende Zeile hinzugefügt. Der Standardwert ist 200.
GATSBY_CONCURRENT_DOWNLOAD=50

Ich bin mir nicht sicher, ob es dein Problem löst, aber vielleicht hilft es jemandem :)

@ rishabhaggarwal2 Es gibt ein ähnliches Problem, das so klingt, als ob es das ist, was Sie erleben, wo es beim Abrufen von Daten aus einer Online-Quelle hängen bleibt. Können Sie versuchen, GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Danke, das hat es für mich behoben. Da ich eine Menge Inhalte von einer Website eines Drittanbieters abgerufen habe, blieb das Herunterladen der Inhalte hängen. (97% - so nah und doch so fern)