Gatsby: [bogue fsevents] Coincé aux "nœuds source et transformation" / "createPagesStatefully" sur MacOS

Mise à jour - J'ai testé en commentant le fichier gatsby-node.js et la construction a progressé à une occasion, mais j'ai ensuite essayé à nouveau et le faire et il est resté bloqué au même endroit.

Y a-t-il une chance que cela soit dû à mon ancien ordinateur, le Macbook Pro 2010 (mis à niveau vers 8 Go de RAM et un SSD), ne m'a pas encore arrêté, mais je sais que ses jours sont limités. C'est un passe-temps pour moi et j'ai de jeunes enfants, donc les dollars n'ont pas été dépensés pour un nouvel ordinateur car celui-ci a bien fonctionné avec le Ram et le SSD mis à niveau.

J'ai essayé de revenir à gatsby 2.13.52 qui était la dernière version sur laquelle j'étais stable, j'ai également essayé de revenir à la 16.8.6.

Fait intéressant, je l'ai fait construire avec succès une fois lorsque je suis revenu à 16.8.6, mais après cette première fois, il a raccroché au même endroit, ce qui est vraiment un comportement étrange pour moi.

Je peux aussi, rarement, sans raison que je peux discerner le faire construire correctement. Il ne semble pas y avoir de rime ou de raison pour laquelle cela se produit. J'ai passé quelques heures à chercher des modèles ou des erreurs qui pourraient en être la cause, mais je n'ai rien trouvé. J'ai examiné https://github.com/gatsbyjs/gatsby/issues/6654 et j'ai essayé certains des articles en vain.

C'est l'un des bogues les plus étranges que j'aie jamais rencontrés car le comportement semble changer sans qu'il y ait de changement perceptible dans le code. Dans certains cas, la construction se bloque aux nœuds source et de transformation (60% du temps), dans certains cas, elle se bloque à Créer des pages avec état (20%), dans certains cas, elle se construit avec succès (20%). Je l'ai fait afficher ces trois comportements sans changer une ligne de code.

J'ai également reproduit ce comportement dans gatsby-starter-blog, ce qui est vraiment étrange. Encore une fois, cela me fait penser que c'est un problème de mon côté au niveau local. Fait intéressant, il ne se bloque qu'à createPagesStatefully .

Je commence maintenant à penser que cela a quelque chose à voir avec une bibliothèque qui a été mise à jour automatiquement par homebrew - dont je n'ai aucune idée mais c'est la seule chose à laquelle je pense que je n'ai pas testé.

Voici une liste des choses que j'ai essayées jusqu'à présent:

• Changement de version de nœud, essayé 12, 10 et 8

• Revenir à un point précédent de mon historique de commit qui fonctionnait - il échoue toujours maintenant.

• Commenter les plugins et les zones de gatsby-config

• Commenter le contenu de mon gatsby-node.js

• Testez-le à nouveau sur Netlify, toujours construit avec succès, ce qui me fait penser qu'il doit avoir quelque chose à voir avec mon ordinateur.

• Suppression des 4 pages de mon répertoire src / pages et mise dans un fichier index.mdx très basique

• Suppression de tous les fichiers node_module et lock, réinstallation

• Redémarrage de l'ordinateur

• Créer un nouvel espace de travail de fil avec de nouveaux clones du thème / démarreur de Github.

• Test de gatsby-starter-blog, comportement similaire mais il se bloque sur createPagesStatefully

Bonjour,

Je ne peux pas faire grand-chose, mais je confirme que je vois ce problème sur un certain nombre de démarreurs Gatsby. Et, comme vous le faites remarquer, il décide parfois simplement de construire ou d'arrêter de construire, suspendu soit aux "nœuds source et transformation", soit à createPagesStatefully.

Assez frustrant et conduisant à essayer les tentatives les plus scandaleuses pour y remédier.

Je n'ai pas été témoin de ce problème mais cela semble gênant et j'aimerais vraiment connaître la raison de ce comportement de votre côté.

Préparation
Vous devriez essayer d'utiliser le débogueur de nœud pour aller à la racine du problème. Une tâche dans votre package.json ressemblerait à ceci. Si vous utilisez VSCode, vous pouvez activer "Auto Attach" pour utiliser le débogueur interne avec cette tâche (assurez-vous d'utiliser le terminal interne à cet effet)

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

Le débogage fonctionnera bien sûr avec n'importe quel IDE, assurez-vous simplement de connecter correctement votre débogueur.

1. Variante: Reproductiion minimale
Vous avez mentionné createPagesStatefully comme source du problème. Si vous êtes sûr que c'est la source du problème, vous pourriez peut-être créer un tout petit projet pour le reproduire. Laissez tomber tous les démarreurs, utilisez simplement gatsby directement et utilisez createPagesStatefully à gatsby-node.js avec quelques exemples qui imitent les choses que font vos débutants. Ensuite, lancez gatsby et déboguez-le via node inspect.

De cette façon, vous pourriez trouver où il se bloque.

2. Alternative: dans votre projet / starter
Vous pouvez bien sûr essayer de déboguer le problème dans votre projet avec la même technique. Mais peut-être avez-vous plusieurs problèmes qui s'empilent et brouillent votre vision de la cause des problèmes. J'essaierais donc toujours d'obtenir une reproduction minimale avant de commencer le débogage.

Bonne chance.

Alors ... j'ai rencontré un comportement étrange avec les fichiers de verrouillage. Peut-être que quelqu'un qui en sait plus pourrait me diriger dans la bonne direction. Dans le processus d'essayer d'obtenir une version minimale de travail, j'ai essentiellement réduit à une installation de Gatsby "bonjour le monde" et cela ne fonctionnait toujours pas, ce qui était vraiment étrange.

Là où cela est devenu encore plus étrange, c'est que le monde réel de gatsby-starter-hello fonctionne et se construit bien sur mon ordinateur. MAIS ... si je supprime le fichier de verrouillage et que j'obtiens du fil pour reconstruire un nouveau fichier de verrouillage, la construction commence à échouer, suspendue à la source et transformer les nœuds. Je pourrais obtenir mon implémentation épurée et minimale à construire si je copiais le fichier de verrouillage de "hello-world" et l'utilisais. Donc, ma théorie actuelle est qu'il y a une sorte de problème de version dans mes fichiers de verrouillage qui cause ce problème, mais je suis coincé ici.

J'ai également supprimé toutes mes installations homebrew et réinstallé node, yarn, git, etc. Juste pour m'assurer que ce n'était pas quelque chose d'amusant.

Merci @ehowey d' avoir soulevé cette question ... Je pensais que c'était juste moi parce que c'était assez intermittent (mais cela arrive plus de 50% du temps). J'ai fait la même chose que vous pour essayer de déboguer la situation. Lorsque je m'accroche à ⠙ source and transform nodes cela signifie généralement que je dois tuer mon terminal.

Si je trouve quelque chose, je vous le ferai savoir. Et je vais aussi regarder ce fil.

@georgiee - merci pour les informations --inspect. Je vais voir si je peux faire fonctionner le débogage des nœuds avec WebStorm.

J'aime aussi votre idée d'une reproduction minimale. Mais cela prendra du temps pendant que je comprendrai Gatsby un peu plus profondément.

Actuellement, il est suspendu aux "nœuds source et transformation". Rarement, il le fait créer des pagesStatefully et s'y bloque. Sinon, il se construit normalement.

Je suis actuellement confronté au même problème après avoir fait une "mise à niveau de fil" pour corriger une dépendance vulnérable. Voici ma configuration:

Système:
Système d'exploitation: macOS 10.15
Processeur: (4) Processeur Intel (R) Core (TM) i7-7567U x64 à 3,50 GHz
Shell: 5.7.1 - / bin / zsh
Binaires:
Nœud: 12.8.1 - / usr / local / bin / node
Fil: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
Langues:
Python: 2.7.16 - / usr / local / bin / python
Navigateurs:
Chrome: 76.0.3809.132
Firefox: 68.0.2
Safari: 13,0
npmPackages:
gatsby: ^ 2.13.42 => 2.14.7
image-d'arrière-plan gatsby: ^ 0.8.3 => 0.8.6
image-gatsby: ^ 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-casque: ^ 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-typographie: ^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts: ^ 1.1.0 => 1.1.0
gatsby-remarque-images: ^ 3.1.10 => 3.1.19
gatsby-remarque-relative-images-v2: ^ 0.1.5 => 0.1.5
gatsby-remarque-responsive-iframe: ^ 2.2.5 => 2.2.10
gatsby-source-filesystem: ^ 2.1.6 => 2.1.18
gatsby-transformer-remarque: ^ 2.6.12 => 2.6.19
gatsby-transformer-sharp: ^ 2.2.5 => 2.2.12

Je suis actuellement confronté au même problème après avoir fait une "mise à niveau de fil" pour corriger une dépendance vulnérable. Voici ma configuration:

Mise à jour: j'arrive à réparer les choses en restaurant mon ancien fichier "yarn.lock".

@ hbthen3rd

Mise à jour: j'arrive à réparer les choses en restaurant mon ancien fichier "yarn.lock".

Mon expérience est que le problème peut disparaître sans raison claire pour revenir plus tard. Vous constaterez peut-être que le problème revient malgré la restauration de yarn.lock. Tenez-nous au courant.

Voici une reproduction minimale utilisant gatsby-starter-hello-world:

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

Le fichier de verrouillage actuel inclus dans le dépôt est celui qui échoue pour moi. J'ai également inclus des copies dans le repo de yarn-working.lock et yarn-notworking.lock . Espérons que cela facilite le dépannage pour quelqu'un.

Mon environnement actuel:

Système:
Système d'exploitation: macOS High Sierra 10.13.6
Processeur: (2) x64 Intel (R) Core (TM) 2 Duo CPU P8600 à 2,40 GHz
Shell: 3.2.57 - / bin / bash
Binaires:
Nœud: 10.16.3 - / usr / local / bin / node
Fil: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
Langues:
Python: 2.7.10 - / usr / bin / python
Navigateurs:
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

Je rencontre le même problème.

Une direction que j'ai trouvée:

1. La rétrogradation de gatsby-plugin-sitemap de 2.2.9 à 2.2.6 résolu le problème avec yarn develop .

   • C'est étrange car gatsby-plugin-sitemap ne devrait pas affecter la construction du développement.

2. yarn build ne fonctionne toujours pas mais quand je supprime gatsby-plugin-sitemap ma configuration, yarn build fonctionne à nouveau.

@sharvit Je peux signaler que cela n'a pas fonctionné dans mon cas. Heureux que cela vous ait corrigé, je pense que cela a finalement quelque chose à voir avec les fichiers de verrouillage et un problème de version étrange au plus profond du fichier de verrouillage.

J'ai réussi à revenir à une version fonctionnelle, la plupart du temps, peut-être 8/10 fois en revenant à un ancien fichier de verrouillage et en faisant du copier-coller. Je peux maintenant également CTRL + C pour forcer la fermeture de la construction si elle se bloque, ce que je n'ai pas pu faire à un moment donné de ce processus. Je ne sais pas ce qui le corrige dans le fichier de verrouillage, mais je pense que les indices sont dans le référentiel que j'ai publié ci-dessus avec deux copies d'un fichier de verrouillage, une qui fonctionne et une qui ne fonctionne pas. C'est une étrange bête de bogue. Habituellement, dans le domaine informatique, les choses fonctionnent ou ne fonctionnent pas de manière rassurante.

@steinitz Une chance de votre côté? J'ai eu ce que vous avez mentionné. Cela semblait aller mieux, plutôt bien mais pas parfait et maintenant échoue presque à chaque fois. Assez frustrant.

@ehowey

Comme vous pouvez l'imaginer, en raison de la nature répétitive de ce problème, j'hésite à le signaler. Voici un exemple typique:

Après avoir supprimé le répertoire node_modules, suppression de yarn.lock puis exécution
npx yarn-upgrade-all
et
yarn install
tout allait bien.

Puis, juste maintenant, en réponse à votre message, j'ai essayé
yarn start
Résultat: il se bloque à nouveau à
source and transform nodes

Je suppose qu'il y a deux choses sensées à faire:

1. suivez les conseils de @georgiee pour que le débogage de Webstorm fonctionne avec
   node --inspect et voyez si je peux repérer des problèmes évidents
2. mettre Gatsby de côté pendant un moment pour voir si une personne intelligente résout le problème

Mettre à jour:

ctl-C'd le processus bloqué ci-dessus (qui n'a pas utilisé pour arrêter le processus bloqué qui était doublement ennuyeux).
Puis yarn start est resté bloqué sur createPagesStatefully .
ctl-C'd encore, un autre yarn start - bloqué sur source and transform nodes
ctl-C'd une fois de plus (pour le plaisir) - cette fois yarn start fonctionné et il fonctionne

Je ne sais pas quoi en penser, mais voilà.

C'est similaire à ce que je vois, ce soir, il semble pire peut-être que la construction réussit 1/10 fois ou moins. Du point de vue de la programmation / codage, c'est un comportement très étrange. Pour l'anecdote, il semblait mieux fonctionner il y a quelques jours à 2.15.1 puis aujourd'hui à 2.15.6. Je me demande également quels points communs nous partageons tous qui sont à l'origine de ce bug. Pouvez-vous exécuter la commande gatsby info --clipboard et la publier?

Ce n'est évidemment pas très répandu sinon il y aurait un flot de rapports, mais ce n'est pas seulement moi comme je le pensais au départ. Nous semblons tous utiliser du fil également, ce qui est une exigence pour moi car je travaille sur des thèmes dans un espace de travail de fil. Je suis toujours en mesure de reproduire cela sur le gatsby-starter-hello-world, donc je pense que c'est un problème de dépendance ou un conflit dans les fichiers de base de gatsby.

@ehowey voici le gatsby info vous avez demandé

Système:
Système d'exploitation: macOS 10.14.6
Processeur: (4) Processeur x64 Intel (R) Core (TM) i7-5557U à 3,10 GHz
Shell: 3.2.57 - / bin / bash
Binaires:
Nœud: 12.9.1 - / usr / local / bin / node
Fil: 1.17.3 - / usr / local / bin / yarn
npm: 6.11.2 - / usr / local / bin / npm
Langues:
Python: 2.7.16 - / usr / local / bin / python
Navigateurs:
Chrome: 76.0.3809.132
Firefox: 68.0.1
Safari: 12.1.2
npmPackages:
gatsby: ^ 2.14.3 => 2.14.7
image-gatsby: ^ 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-casque: ^ 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-remarque-images: ^ 3.1.19 => 3.1.19
gatsby-remarque-prismjs: ^ 3.3.9 => 3.3.9
gatsby-source-filesystem: ^ 2.1.18 => 2.1.18
remarque-gatsby-transformer: ^ 2.6.19 => 2.6.19
gatsby-transformer-sharp: ^ 2.2.12 => 2.2.12
npmGlobalPackages:
gatsby-cli: 2.7.40

J'avais le même problème: le site était parfaitement construit sur Netlify, mais accroché sur ma machine de développement avec à la fois gatsby build et gatsby develop .

Après avoir joué avec les versions de package, j'ai remarqué que le retour de gatsby-plugin-sitemap de la version 2.2.10 à 2.2.9 a résolu le problème pour moi. Curieusement, certaines personnes ici semblent avoir des problèmes avec la version 2.2.9, ce qui pourrait signifier que le problème se trouve ailleurs.

Edit: Parlé trop tôt, Gatsby se bloque toujours aux étapes "source et transformer les nœuds" et "createPagesStatefully", bien que beaucoup moins fréquemment.

@goblindegook cela semble être un modèle courant avec ce problème particulier. Parce que le problème va et vient, apparemment avec la météo, l'heure de la journée, le temps écoulé depuis le démarrage ... vous pouvez croire que quelque chose que vous avez fait l'a résolu - seulement pour qu'il se reproduise.

En rencontrant également ce problème, la note de gatsby-plugin-sitemap rétrogradée à 2.2.6 et cela semble l'avoir résolu

FWIW, j'éprouve également cela mais n'utilise ni yarn ni gatsby-plugin-sitemap .

Mon gatsby info au cas où cela aiderait:

  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

Pour moi, nettoyer le cache avec gatsby clean résolu le problème.

Je suis encore en train de chasser, essayant de comprendre cela. Encore un problème pour moi. Quelqu'un sait-il si cela pourrait être lié au passage de babel 7.0.0 -> 7.5.5. Ce changement s'est produit à peu près au moment où j'ai commencé à rencontrer ce bogue et coïncide avec le fait que je commence à voir des problèmes ... J'ai essayé de faire fonctionner les résolutions de fil afin de fixer les versions de babel à 7.0.0 mais je n'ai pas réussi ceci encore.

Je pense que je peux offrir un aperçu - j'ai commencé à avoir ce problème lorsque, à mi-chemin en ajoutant des plugins à un projet, j'ai mis à jour gatsby-cli dans une autre fenêtre de terminal. Lancer gatsby clean dans mon projet a fonctionné.

de https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 - Je vois également ce problème mais gatsby clean ne l'a pas résolu. Il semble que l'impression de la CLI se bloque, c'est pourquoi le redimensionnement du terminal le corrige ?? 🤷‍♂ 😕 ❓❗️

Le redimensionnement de la fenêtre du terminal semble résoudre le problème pour moi! Je ne l'ai pas testé de manière très approfondie, est-ce que d'autres personnes ayant ce problème peuvent également essayer cela? Quel bogue étrange et solution potentiellement étrange.

Je suis confronté au même problème: gatsby reste souvent bloqué sur les nœuds «source et transformation» ou «createPagesStatefully», et je n'utilise pas de plug-ins source. Je n'ai rencontré que récemment le correctif "Redimensionner la fenêtre du terminal" et je suis à 140% perplexe quant à la façon dont cela le corrige, mais c'est le cas. Cela semble être un problème assez sérieux!

@JaKXz - Merci! Cela me rendait fou. Le correctif semble redimensionner la fenêtre du terminal dans VS Code. Faites-le simplement glisser un peu vers le haut ou le bas et la tâche de développement avance avec bonheur. J'ai testé dans quelques cas différents à la fois du fil et du npm, des espaces de travail et non. Semblait travailler dans tous ces cas pour moi. Il semble également se figer ou se bloquer à createPagesStatefully plus souvent que source and transform nodes maintenant pour moi. Je vais laisser le problème ouvert pour le moment, cela devra peut-être être résolu de manière moins «hacky» par quelqu'un avec plus de savoir-faire que moi.

@ehowey J'ai le même problème et déplacer la fenêtre du terminal dans vscode fonctionne (je ne pouvais pas le croire en lisant ce problème jusqu'à ce que je me sois essayé).
Savez-vous si cela ne se produit que sur VS Code?

J'ai ce problème sur iTerm 2, donc ce n'est pas spécifique à VS Code.

Mon problème a également été dans iTerm 2

Terminal Webstorm, Terminal Mac, iTerm

Le correctif du terminal de redimensionnement a-t-il fonctionné pour vous tous dans différents environnements de développement?

De mon côté, le redimensionnement du terminal a fonctionné sur iTerm et VSCode (il a fallu quelques essais pour reproduire le problème sur iTerm)

L'astuce du terminal de redimensionnement fonctionne de manière fiable pour moi dans iTerm 2.

Oui, le redimensionnement d'iTerm 2 fonctionne parfaitement

Si le redimensionnement fonctionne, je soupçonne que ce bogue est lié au tampon, quelque part a besoin d'un flush stdout.

Ce genre de problème semble être un problème lié au noyau + shell. Probablement d'une manière ou d'une autre, le nœud interagit avec votre noyau et / ou votre shell. Je dis cela uniquement parce que je n'arrive pas à reproduire les problèmes sous Linux ou Windows. Je n'arrive pas à trouver de problèmes connus, donc soit a) c'est une combinaison de modèles de code uniques à Gatsby + l'interaction avec le système, soit b) je ne connais tout simplement pas la bonne question à poser.

Si le redimensionnement du terminal résout le problème, il peut s'agir d'un problème entre le nœud et kqueue provoquant un blocage dans la boucle d'événements. Le redimensionnement du terminal envoie au processus un signal SIGWINCH, qui interrompt la boucle d'événements, ce qui le libère et lui permet de continuer.

Pouvez-vous essayer d'exécuter kill -SIGWINCH ${pid} sur le processus en cours lorsqu'il se bloque? Devrait agir de la même manière que le redimensionnement du terminal.

Je suis également intéressé à savoir si cela se produit ou non dans tous les shells. Sur la base des informations jusqu'à présent, cela a échoué dans bash et zsh , et c'est probablement l'un des facteurs communs entre tous les émulateurs de terminaux. Pouvez-vous essayer un ou plusieurs des sh , csh , ksh , tcsh , etc ...?

Si le problème se produit dans tous les shells, alors je suppose que c'est la façon dont le noyau gère la boucle d'événements du nœud. Cela pourrait également être la raison pour laquelle il s'agit d'un problème intermittent. Si une fonction prend moins de temps processeur (peut-être à cause de la charge variable du système), elle peut se bloquer trop longtemps, et peut-être que le noyau essaie de réutiliser un nœud d'événement quelque part, entraînant un blocage? Je ne suis pas très familier avec les composants internes de l'API, mais je parie que source and transform nodes est assez gourmand en IO pour le système de fichiers. Cela signifie qu'il y a probablement beaucoup de déchargements en cours, alors qui sait ce qui se passe vraiment aux niveaux inférieurs.

Je pense que ce serait une bonne idée d'essayer de réduire la surface de ce bogue. Cela se produit le plus souvent dans source and transform nodes , cela ressemble à cela, alors essayez peut-être de le réduire à quel plugin bloque. Essayez d'ajouter les lignes suivantes à 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       })));

Puis lancez node inspect node_modules/.bin/gatsby develop . Il se cassera dès qu'il démarre, donc vous devez frapper c lorsque vous arrivez à l'invite debug> , et attendre que cela continue. Quand il casse sur cette ligne debugger , écrivez exec console.log(plugin) , et notez ce qu'il dit dans resolve . Puis appuyez sur c pour continuer. Faites ceci jusqu'à ce qu'il se bloque ... s'il se bloque.

En raison de la nature de la boucle d'événements, je parie qu'elle ne se bloquera même pas lors du débogage. Ces interruptions sont probablement suffisantes pour le maintenir sur une piste. Les bogues asynchrones peuvent être très difficiles à localiser. S'il ne se bloque pas lors de l'utilisation du débogueur, remplacez cette ligne debugger par:

reporter.log(plugin.resolve);

Espérons que cela changera quelque chose. Ce serait bien de voir quel plugin est à l'origine du blocage. Si nous pouvons comprendre cela, nous pourrions être en mesure de déterminer ce qui doit être optimisé / refactorisé pour résoudre ce problème.

Le redimensionnement fonctionne pour moi aussi, j'utilise zsh comme shell VSCode.

@ Js-Brecht - Merci d'avoir pris le temps d'une réponse aussi détaillée. Je ne savais pas exactement où je devais saisir kill -SIGWINCH ${pid} . Je ne pouvais pas le faire pendant le processus de construction.

Avec le débogueur, le code suivant est sorti ... au-delà de moi pour lui donner un sens. En fait, je suis resté coincé dans le débogueur mais .exit fonctionnait toujours.

⠋ 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, en utilisant Terminal, le redimensionnement a fonctionné pour moi.

@ehowey Juste pour que je sache que je vous comprends bien, il s'est bloqué pendant que vous étiez dans le débogueur? Dans ce cas, il me semble que gatsby-source-filesystem est le coupable, ce qui a du sens pour moi ... en particulier à cause de problèmes existants liés à Gatsby.

J'aimerais voir si le plugin peut gérer un test. S'il se bloque lors de l'exécution des tests, je pense que ce sera un moyen facile de voir où il échoue. Sinon, eh bien ... devra juste faire quelques dissections / débogages, ce qui sera difficile pour moi, car je n'ai pas MacOS.

Pouvez-vous télécharger le référentiel gatsby principal et exécuter les tests 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'

De plus, faites-vous tout cela avec votre référentiel de reproduction minimal? Je vois que gatsby-plugin-mdx été exécuté deux fois, ce qui me dit que ce n'est pas un dépôt barebones. Dans un monde parfait, cela ne devrait pas avoir d'importance, mais je pense qu'il serait préférable d'exécuter une configuration aussi simple que possible. Si vous ne parvenez pas à le faire échouer de manière fiable avec le dépôt minimal, utilisez celui qui échoue le plus régulièrement (au même endroit, à chaque fois (ou près de))

😉

kill -SIGWINCH ${pid} doit être exécuté à partir d'une autre instance de shell. Lorsque la construction se bloque, ouvrez une autre fenêtre / onglet de terminal et exécutez la commande à partir de là. Ce petit extrait devrait fonctionner:

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

S'il y a des erreurs, essayez d'exécuter les commandes séparément:

# 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

Si vous arrivez les mains vides après avoir exécuté les tests, je pense qu'il sera utile d'avoir un vidage de mémoire, afin que nous puissions obtenir une trace de la pile. Mais, une étape à la fois.

@ Js-Brecht Désolé pour les réponses plus lentes ... c'est vraiment juste un passe-temps secondaire que je pratique pendant mon temps libre le soir.

J'ai donc couru la même chose à l'intérieur du démarreur de gatsby hello world - aussi nu que possible. Désolé, je l'ai déjà exécuté dans mon espace de travail principal sur un projet avec lequel j'avais des problèmes. Je l'ai déjà répliqué sur des démarreurs, donc je ne pense pas que cela se rapporte à un plugin mais plutôt à quelque chose dans le noyau de gatsby.

Il se bloque sur les nœuds source et de transformation, ce qui me donne la sortie suivante:

< 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

Voici un vidage de la commande gatsby info au cas où cela serait utile:

  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

En remarque, lorsque j'utilise votre commande de débogage, elle se bloque sur les nœuds source et de transformation. Quand j'utilise gatsby develop, c'est principalement suspendu à createPagesStatefully maintenant pour moi. Désolé, je sais que c'est vraiment étrange. Pour être honnête, je ne sais pas combien de travail cela vaut de votre côté. L'astuce de redimensionnement de la fenêtre du terminal fonctionne à chaque fois pour moi et pour les autres. C'est un correctif piraté mais il ne doit pas affecter autant d'utilisateurs, sinon les problèmes seraient inondés.

Cela a commencé à se produire ici aussi. L'astuce _resize the terminal_ le résout; très étrange!

+1 Ne fonctionne pas dans iTerm2, mais fonctionne dans le terminal 🤷‍♂️

@ehowey La majorité de ce qui se passe pendant la construction est définie par un plugin ou un autre. Gatsby est livré avec eux en tant que dépendances; Je suppose qu'ils pourraient être considérés comme des plugins principaux. Le noyau Gatsby expose une API, qui recherche les points de terminaison définis dans les plugins, et leur transmet une série d'arguments qui incluent des actions / objets définis dans le noyau. Alors oui, ce qui se passe pourrait se produire dans le noyau, mais il faut d'abord faire appel à un plugin, et ces plugins définissent un contexte spécifique pour l'API. J'essaie de déterminer le contexte qui entraîne le blocage de la construction et je dois également vérifier que le problème ne se produit pas dans le plugin lui-même.

Puis-je vous demander de changer ces lignes?

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

Veuillez exécuter ceci et copier / coller l'intégralité de la sortie (vous pouvez même la joindre à votre réponse en tant que fichier .txt ). Ce sera beaucoup plus détaillé et une grande partie des informations sera probablement inutile, mais 🤷‍♂.

Une fois que vous avez fait cela, j'aimerais voir si l'augmentation du pool de threads du nœud fait une différence. J'ai remarqué d'autres problèmes qui mentionnent les mêmes problèmes ou des problèmes similaires. La plupart du temps, ils se produisent dans source and transform , et certains disent que cette étape prend une éternité, ou se verrouille complètement. Donc, je veux voir s'il s'agit d'une sorte de blocage dans le système de fichiers io ... l'accès au système de fichiers asynchrone est déchargé par nœud vers différents threads, et, par défaut, le nœud n'a qu'un pool de 4 threads pour l'espace utilisateur. Si ceux-ci se remplissent et qu'il doit effectuer plus de déchargement, les tâches seront mises en file d'attente dans la boucle d'événements principale, en attendant un thread. Cela pourrait, potentiellement, mettre l'ensemble du programme à l'arrêt ... jusqu'à ce qu'un thread devienne disponible. Gatsby maintient un cache sur le système de fichiers, donc peut-être qu'il y a une collision quelque part, et s'il y a une sorte de blocage, alors peut-être que les threads attendent un timeout / interruption avant de continuer, et s'il y en a des dizaines (ou des centaines, même) des événements d'accès au système de fichiers, ils pourraient tous attendre le même délai d'expiration et provoquer une accumulation de tout. Vous pouvez voir que cela pourrait entraîner une augmentation assez rapide des temps d'attente.

L'augmentation de la taille du pool peut aider à alléger une partie du trafic ... ou, cela peut se produire de la même manière, juste avec plus de threads 😆.
Essayez la commande suivante:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht Changer la taille du pool de threads ne semblait pas faire beaucoup de différence.
J'obtiens la sortie suivante de la commande standard gatsby develop avec les changements que vous avez mentionnés ci-dessus. Toujours sur le démarreur de base hello-world gatsby.

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

Voici un exemple où il se bloque sur createPagesStatefully . Je l'ai eu pour continuer la construction en redimensionnant la fenêtre du terminal. Quelle est internal-data-bridge une chance qui pourrait être le coupable d'une manière ou d'une autre? Cela figurait dans les deux commandes que vous m'avez demandé d'exécuter jusqu'à présent.

Pouvez-vous montrer sur quelle ligne il était accroché?

createPagesStatefully dev-404-page

Je ne suis pas sûr à 100% si la partie dev-404-page était encore là, mais elle s'est accrochée à la première instance de createPagesStatefully

Merci. J'aimerais essayer d'autres changements maintenant, si cela ne vous dérange pas.

Veuillez mettre à jour les lignes indiquées dans les fichiers suivants:

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

Je soupçonne que chokidar pourrait être en faute ici. Il a été mis à niveau vers la v3.x il y a environ un mois, et il semble qu'ils aient soit commencé à utiliser fsevents , soit qu'ils aient fait quelque chose qui a causé un comportement erroné par rapport à fsevents . Ils ont des problèmes ouverts similaires à ceux auxquels nous sommes confrontés ici, avec un nœud suspendu lors de l'utilisation de chokidar.watch() . Cela semble convenir, car il est localisé sur MacOS car fsevents étant un processus Mac, et la construction semble échouer dans les modules où elle est utilisée, ou dans les modules qui écrivent / traitent des fichiers qui sont probablement surveillés.

chokidar.watch() existe également dans gatsby-source-filesystem , et c'est là qu'il échouait avec votre autre dépôt, @ehowey; sans oublier que gatsby-source-filesystem n'est pas appelé dans votre dépôt minimal, ce qui explique en quelque sorte pourquoi il dépasse source and transform . Il y a des instances de chokidar avant internal-data-bridge , mais je pense à des emplacements qui n'affectent pas la construction (par exemple query-watcher ). Cependant, je crois que internal-data-bridge est la raison pour laquelle il se bloquait lors de l'exécution du débogueur; et dans une course directe, cela affectait probablement les étapes ultérieures de la construction.

Faites-moi savoir si cela résout les problèmes, ou même si cela va plus loin que ce qu'il a été. :doigts croisés:

@ Js-Brecht Vous allez quelque part! J'ai couru gatsby develop probablement 15 fois. Il n'a jamais été accroché sur source and transform nodes ou createPagesStatefully mais il a semblé se bloquer, peut-être 2/10 fois, sur start webpack server . Je pourrais ajouter cela à l'astuce de redimensionnement du terminal. Avez-vous manqué une instance de chokidar / fsevents qui serait liée à start webpack server ?

En passant, il semblait également passer les étapes du processus de développement beaucoup plus rapidement qu'auparavant si cela avait quelque chose à voir avec cela?

C'est vraiment bon à entendre. J'ai laissé exprès une instance de chokidar, et c'est juste après avoir terminé le bootstrap et démarré le serveur. Il est dans node_modules/gatsby/dist/commands/develop.js vers la fin de la fonction startServer() . Je ne suis pas devant un ordinateur pour le moment, ou je vous donnerais une différence.

Vous pouvez trouver la ligne exacte en faisant:

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

J'étais à peu près sûr que si cela corrigeait le bootstrap, il devrait encore se bloquer sur le serveur. Faites-moi savoir si cela permet de fonctionner de manière fiable, et je soumettrai un PR et me chargerai d'en informer les gens.

Je ne suis en fait pas surpris que cela accélère le fonctionnement. La construction sur un projet barebones me prend généralement peut - fsevents est censé accélérer les choses et soulager une grande partie de la charge du processeur, mais il se passe quelque chose de drôle qui le bloque à la place.

@ Js-Brecht Mon chapeau te va. Je n'ai aucune idée de la façon dont vous avez sorti ce lapin d'un chapeau et que vous avez corrigé un bug aussi étrange à distance mais bon travail! J'attendrai que le diff apporte des modifications à develop.js car je ne veux pas changer la mauvaise chose, mais je soupçonne que cela résoudra le problème car il se bloquait à cette toute dernière étape quand il démarre le serveur quelques des fois.

Voici le diff:

node_modules/gatsby/dist/commands/develop.js

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

J'apprécie vraiment votre aide pour exécuter tous ces tests. Cela a été délicat, mais cela a été l'occasion de creuser dans les internes de MacOS, et j'aime toujours apprendre de nouvelles choses: légèrement_smiling_face:

S'il vous plaît laissez-moi savoir comment ça se passe; pas encore complètement sorti du bois: sueur_ sourire :.

Travaux! Je viens de courir gatsby develop 10+ fois et cela a fonctionné parfaitement. Merci pour votre aide dans cette étude. J'espère que cela améliorera le groupe d'entre nous qui vit cela!

Génial! Ici dans peu de temps, quand j'aurai quelques minutes, je préparerai un PR. Une fois que c'est fait, vous pourrez utiliser gatsby-dev-cli avec mon dépôt afin que vous ayez un environnement de développement fonctionnel jusqu'à ce qu'un correctif soit publié (si vous n'êtes pas familier avec gatsby-dev-cli , je peux Aidez-moi). Je pourrais essayer de vous recruter pour tester les changements de toute façon, car je n'ai pas le bon système d'exploitation ... il en va de même pour tous les autres utilisateurs de ce fil qui rencontrent ce problème.

Je posterai ici quand ce sera fait.

J'ai trouvé un autre problème distinct qui cause également ce symptôme - https://github.com/gatsbyjs/gatsby/issues/17935

Si quelqu'un utilise LokiJS et que le redimensionnement du terminal ne le résout pas, c'est probablement le problème que j'ai trouvé.

Hé les gars, @ehowey , veuillez consulter PR # 17938. Si quelqu'un est prêt à tester, s'il vous plaît faites et laissez tomber une ligne sur le PR.

Vous pouvez récupérer mon dépôt et l'utiliser comme source gatsby dans votre site en utilisant gatsby-dev-cli . Tout d'abord, vous avez besoin de gatsby-dev-cli

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

Ensuite, clonez simplement le référentiel et démarrez-le.

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

Accédez ensuite au site dans lequel vous souhaitez utiliser le repo et exécutez gatsby-dev

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

dans mon cas, j'utilise OSX et IntelliJ, je devais:

• Fermer le projet dans IntelliJ
• Réessayer ( npm start )
• et rouvrir le projet dans Intellij
  Je suppose que le problème est lié aux fichiers d'indexation IntelliJ

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

L'un de vous est-il prêt à tester # 17938?

Je devrais pouvoir jeter un coup d'œil plus tard ce soir quand je serai à la maison. Merci pour tout votre travail là-dessus!
Le 1 octobre 2019, 10h23 -0600, Jeremy Albright [email protected] , a écrit:

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel
L'un de vous est-il prêt à tester # 17938?
-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désactivez le fil de discussion.

Une mise à jour sur le correctif pour cela? Il se fige à la source et transforme les nœuds pour moi et mon ami également après avoir essayé [Firebase Source] Fetching data for ...

Le redimensionnement du terminal ne semble malheureusement pas résoudre le problème pour nous

@ rishabhaggarwal2 Il y a un problème similaire qui semble être celui que vous rencontrez, où il se bloquera lors de la récupération de données à partir d'une source en ligne. Pouvez-vous essayer d'utiliser GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Voyant cela aussi. Impossible d'exécuter gatsby develop localement au démarrage de lumen. Continue de s'accrocher à createPageStatefully ou source and transform nodes

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

Pour quiconque trouve ce problème, essayez

CHOKIDAR_USEPOLLING=1 gatsby develop

Cela devrait désactiver fsevents sur MacOS, ce qui semble être une solution de contournement fiable.

@ Js-Brecht Je confirme que cela semble le résoudre de manière plus permanente que les autres solutions de contournement mentionnées ici. Merci d'avoir partagé.

@steinitz vous dites «plus» en permanence. Voulez-vous dire que cela se produit toujours lorsque vous utilisez ce commutateur?

@ Js-Brecht Non, désolé de ne pas être clair.

Je faisais allusion au fait que d'autres solutions de contournement, y compris la mienne, semblaient fonctionner pendant un certain temps, mais le problème est revenu. Avec votre solution, je l'ai provoqué en apportant des modifications et en relançant gatsby develop (avec votre amélioration) mais la compilation continue de fonctionner.

Cela dit, cela a été un tour de montagnes russes alors je reste préparé émotionnellement: sourire: pour que le problème revienne.

Pour être clair: jusqu'ici, tout va bien.

Oups, mise à jour: j'ai relancé WebStorm pour un test final avant de publier ceci et maintenant il est bloqué sur source and transform nodes dans le terminal WebStorm.

Pour quiconque trouve ce problème, essayez

CHOKIDAR_USEPOLLING=1 gatsby develop

Cela devrait désactiver fsevents sur MacOS, ce qui semble être une solution de contournement fiable.

@ Js-Brecht J'utilise ubutu 18.04 et je rencontre parfois le même problème. Y a-t-il une suggestion pour mon système d'exploitation? Souhaitez-vous fournir des détails sur les causes possibles de ce problème?

Cela a été résolu grâce au travail assidu de @ Js-Brecht et @RomanHotsiy. C'était un problème en amont dans fsevents, bien au-delà de ce que j'aurais pu comprendre par moi-même, et devrait être corrigé dans les futures mises à jour une fois que ces modifications seront implémentées et migreront de fsevents vers gatsby lui-même. Pour l'instant, une solution de contournement fiable consiste à redimensionner la fenêtre du terminal, il existe un moyen de résoudre ce problème dans votre dépôt lui-même qui est discuté ici: https://github.com/gatsbyjs/gatsby/pull/17938 mais vous devrez le refaire corrige après toute modification apportée à votre dossier node_modules et peut ne pas valoir le coup selon la fréquence à laquelle vous mettez à jour les versions de votre package.

Je laisserai le problème ouvert jusqu'à ce que le correctif migre en aval dans gatsby lui-même.

@ Boty22 Ubuntu n'utilise pas fsevents , donc c'est probablement quelque chose de différent. Certains problèmes ont été rencontrés lors de la récupération de données à partir d'un emplacement distant; consultez # 6654 et # 17940 pour plus de détails sur la résolution des problèmes de concurrence.

Question rapide: le redimensionnement de votre terminal vous aide-t-il? Si tel est le cas, il pourrait s'agir de quelque chose de similaire à ce problème.

@ Js-Brecht redimensionner le terminal n'aide pas pour Ubuntu. Je récupère les données d'une table AirTable à l'aide du plugin gatsby-source-airtable BTW

Cela pourrait être le problème. Regardez ce commentaire . Si cela ne fonctionne pas, il serait peut-être préférable d'ouvrir un nouveau ticket

@steinitz désolé, j'ai manqué votre commentaire. Pouvez-vous essayer le correctif décrit dans # 17938? Plus précisément, ici et ici . Si cela ne fonctionne pas, il se passe probablement plus de choses dans votre cas.

Je n'ai eu aucun problème avec CHOKIDAR_USEPOLLING=1 gatsby develop depuis mentionné.

Merci pour la solution de contournement @ Js-Brecht

Je vois cela aussi avec la version 2.15.28 lorsque je construis gatsby. Dois-je arrêter le développement de gatsby dans l'autre terminal? Cela arrive par intermittence

Se produit à nouveau sans que le serveur de développement ne fonctionne. J'ai cependant un blog simple en suivant le tutoriel du blog.

Il semble que ce soit presque toutes les autres courses. Je suis sur un Mac btw

@canvaspixels est-ce que le redimensionnement de la fenêtre du terminal décolle votre build? Si tel est le cas, essayez ceci et faites-nous savoir si cela a aidé https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991

@RomanHotsiy qui le trie en effet! Merci!

Salut tout le monde, la version corrigée de fsevents a été publiée. Vous devriez pouvoir simplement supprimer votre fichier yarn.lock et exécuter à nouveau yarn. Chacune de vos dépendances devrait automatiquement récupérer [email protected] , ce qui devrait résoudre le problème.

Attention, la suppression de l'intégralité de votre fichier yarn.lock peut également entraîner la mise à niveau d'autres packages.

Une autre option plus précise si vous utilisez yarn est de supprimer uniquement les lignes relatives à fsevents dans le yarn.lock et de réexécuter yarn . Cela entraînera uniquement la mise à niveau du package concerné. Par exemple, j'ai supprimé les lignes suivantes:

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

Une autre façon de faire est d'utiliser la fonctionnalité resolutions de Yarn (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/). En ajoutant ce qui suit à votre package.json , puis en exécutant yarn , il mettra également à niveau les dépendances transitives et mettra à jour votre fichier yarn.lock :

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

Une fois que vous avez fait cela et que votre fichier de verrouillage est mis à jour, vous pouvez à nouveau supprimer la propriété resolutions de package.json .

Modifier: version précédente incorrecte des instructions supprimée.

Vous pouvez également exécuter yarn upgrade chokidar@latest . Cela devrait reconstruire le fichier de verrouillage avec la version correcte de fsevents, sans rien toucher d'autre

Oh, attendez. Ce n'est que si vous avez chokidar comme dépendance directe 🙄. Oublié. @karlhorky a raison

J'utilise npm . Supprimer node_modules , exécuter npm i --save [email protected] puis npm i fait l'affaire pour moi. Il a fallu 19 ans pour démarrer et j'utilise le gatsby-lumen-starter comme base.

-- Éditer:

En fait, j'ai terminé ce sur quoi je travaillais, poussé vers Netlify et il était complètement impossible de construire à cause de fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ).

Je suis passé à yarn et j'ai eu le même problème, donc j'ai complètement supprimé fsevents , et maintenant local et netlify fonctionnent tous les deux ...

J'ai eu le même problème et je n'ai pas pu en suivre la raison. Cela m'est arrivé à la fois sur Mac et PC. Pourrait essayer de relier cela à la vitesse d'Internet, mais cela m'est arrivé également lorsque j'étais connecté à un réseau à haut débit. Ce qui semble fonctionner pour moi en ce moment est d'ajouter ceci dans mon env

GATSBY_CONCURRENT_DOWNLOAD=5

et en cours d'exécution avec --v8-pool-size=128

Dans mon cas, cela semble être l'invite de mon pare-feu sur osx. Si je suis assez rapide pour autoriser ou refuser les connexions venant de l'extérieur, cela réussira parfaitement. Le problème est que la boîte de dialogue d'invite apparaît pendant une fraction de seconde et disparaît pendant que Gatsby continue, puis échoue à suspendre l'une des nombreuses étapes mentionnées ci-dessus.
Options:

• désactiver le pare-feu (ne pas avoir cela)
• liste blanche Gatsby (non cohérente entre les projets et les mises à niveau)
• trouver un moyen de s'arrêter à l'invite jusqu'à ce que l'utilisateur sélectionne l'option
• adresse de liaison par défaut à localhost (ne devrait pas nécessiter d'invite pour accepter les connexions entrantes).

@thomasthep L'adresse de liaison par défaut du serveur de développement est déjà localhost. Il n'écoute même pas les connexions externes à moins que vous ne lui disiez d'utiliser votre adresse IP extérieure (ou 0.0.0.0). Et même dans ce cas, il ne démarre le serveur de développement qu'après la fin du bootstrap / build. Si c'est le bootstrap qui provoque l'invite du pare-feu, cela aura plus à voir avec les plugins que vous utilisez, car Gatsby n'atteint pas Internet dans son état par défaut.

Il ne devrait même pas y avoir de connexions "venant de l'extérieur", en général; même lorsqu'un plugin collecte des informations à partir d'une source externe, la connexion provient de votre hôte local, pas de la source externe, et cela est généralement accepté comme une "connexion établie" par la plupart des pare-feu, d'après mon expérience, car la plupart des pare-feu sont configurés pour accepter les connexions sortantes.

Je pourrais voir cela se produire si votre pare-feu est configuré pour bloquer les processus, plutôt que simplement les connexions. Dans ce cas, ce serait Node qui devrait être ajouté à la liste blanche.

Aurait besoin de plus d'informations pour vraiment comprendre pourquoi cela vous arrive. Cependant, il serait probablement plus efficace d'ouvrir un nouveau ticket. Celui-ci avait à voir avec fsevents sur MacOS causant des problèmes, et cela a été résolu, c'est pourquoi il est fermé maintenant. Tout ce qui n'est pas lié à fsevents devrait vraiment avoir son propre problème, pour attirer l'attention qu'il mérite.

Pour mémoire, cela peut également se produire si votre serveur GraphQL fonctionne en mode débogage et qu'il est arrêté à un point d'arrêt.

Pour mémoire: cela a commencé à m'arriver lorsque j'ai ajouté gatsby-source-s3-image et que le bucket s3 a atteint plus de 100 images. Il parcourt les 145 images au stade source and transform nodes et y reste pour toujours. Cela se produit toujours, j'ai essayé les correctifs ci-dessus. Heureusement, cela fonctionne après 5-6 tentatives donc je ne suis pas bloqué.

Redimensionner étrangement la fenêtre du terminal a fonctionné pour moi

Pour moi, limiter les téléchargements simultanés comme décrit ici semble aider.

J'ai ajouté la ligne suivante à mon fichier .env. La valeur par défaut est 200.
GATSBY_CONCURRENT_DOWNLOAD=50

Je ne sais pas si cela résout votre problème mais peut-être que cela aide quelqu'un :)

@ rishabhaggarwal2 Il y a un problème similaire qui semble être celui que vous rencontrez, où il se bloquera lors de la récupération de données à partir d'une source en ligne. Pouvez-vous essayer d'utiliser GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Merci, cela a résolu le problème pour moi. Depuis que je tirais une tonne de contenu d'un site Web tiers, je continuais à télécharger le contenu. (97% - si proche mais si loin)