Gatsby: [error de fsevents] Atascado en "generar y transformar nodos" / "createPagesStatefully" en MacOS

Actualizado: probé comentando el archivo gatsby-node.js y la compilación progresó en una ocasión, pero luego lo intenté de nuevo y lo hice y se quedó atascado en el mismo lugar nuevamente.

¿Hay alguna posibilidad de que esto se deba a que mi computadora antigua, Macbook Pro 2010 (actualizada a 8GB Ram y SSD), no me ha detenido todavía, pero sé que sus días son limitados? Este es un pasatiempo para mí y tengo niños pequeños, por lo que el dinero no ha estado allí para gastar en una computadora nueva, ya que esta funcionó bien con la Ram y SSD mejoradas.

He intentado volver a gatsby 2.13.52, que era la última versión en la que estaba estable, también he intentado volver a reaccionar 16.8.6.

Curiosamente, lo construí con éxito una vez cuando volví a reaccionar a 16.8.6, pero después de esa primera vez colgó en el mismo lugar, lo que es un comportamiento realmente extraño para mí.

También puedo, rara vez, sin ninguna razón que pueda discernir, lograr que se construya bien. No parece haber una rima o una razón para cuando esto sucede. Pasé un par de horas buscando patrones o errores que pudieran estar causando esto, pero no encontré nada. Revisé https://github.com/gatsbyjs/gatsby/issues/6654 y probé algunos de los artículos allí en vano.

Este es uno de los errores más extraños que he encontrado porque el comportamiento parece cambiar sin que haya cambios perceptibles en el código. En algunos casos, la compilación se bloquea en el origen y transforma los nodos (60% del tiempo), en algunos casos se bloquea en Crear páginas con estado (20%), en algunos casos se compila correctamente (20%). He hecho que muestre los tres comportamientos sin cambiar una línea de código.

También he replicado este comportamiento en gatsby-starter-blog, lo cual es realmente extraño. Una vez más, me hace pensar que este es un problema de mi parte a nivel local. Curiosamente, solo se cuelga en createPagesStatefully .

Ahora estoy empezando a pensar que tiene algo que ver con una biblioteca que se actualizó automáticamente por homebrew, de la cual no tengo idea, pero es lo único que puedo pensar que no he probado.

Aquí hay una lista de las cosas que he probado hasta ahora:

• Cambiando versiones de nodo, probé 12, 10 y 8

• Volviendo a un punto anterior en mi historial de confirmaciones que estaba funcionando, todavía falla ahora.

• Comentando complementos y áreas de gatsby-config

• Comentando el contenido de mi gatsby-node.js

• Pruébelo nuevamente en Netlify, aún construido con éxito, que es lo que me hace pensar que debe tener algo que ver con mi computadora.

• Eliminando las 4 páginas en mi directorio src / pages y poniendo un archivo index.mdx muy básico

• Eliminando todos los archivos node_module y lock, reinstalando

• Reiniciando la computadora

• Creando un espacio de trabajo de hilo fresco con nuevos clones del tema / iniciador de Github.

• Probando gatsby-starter-blog, comportamiento similar pero se cuelga en createPagesStatefully

Hola,

Poco puedo hacer, pero confirmar que estoy viendo este problema en varios arrancadores de gatsby. Y, como señala, a veces simplemente decide compilar o dejar de compilar, colgando de "nodos de origen y transformación" o createPagesStatefully.

Bastante frustrante y que lleva a intentar los intentos más extravagantes para solucionarlo.

No fui testigo de este problema, pero esto suena extraño y realmente me gustaría saber la razón de este comportamiento de su parte.

Preparación
Debe intentar utilizar el depurador de nodos para llegar a la raíz del problema. Una tarea en su package.json se vería así. Si está utilizando VSCode, puede habilitar "Auto Attach" para usar el depurador interno junto con esta tarea (asegúrese de usar el terminal interno para este propósito)

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

La depuración, por supuesto, funcionará con cualquier IDE, solo asegúrese de adjuntar su depurador correctamente.

1. Variante: reproducción mínima
Ha mencionado createPagesStatefully como la fuente del problema. Si está seguro de que esa es la fuente del problema, tal vez pueda crear un proyecto muy pequeño para reproducirlo. Deshazte de todos los principiantes, solo usa gatsby directamente y usa createPagesStatefully hasta gatsby-node.js con algunos ejemplos que imitan las cosas que están haciendo tus principiantes. Luego inicie gatsby y depúrelo a través de la inspección del nodo.

De esa manera, puede encontrar dónde cuelga.

2. Alternativa: dentro de su proyecto / inicio
Por supuesto, podría intentar depurar el problema dentro de su proyecto con la misma técnica. Pero tal vez tenga varios problemas que se acumulan y difuminan su vista sobre la causa de los problemas. Así que siempre intentaría obtener una reproducción mínima antes de comenzar a depurar.

Buena suerte.

Entonces ... me encontré con un comportamiento extraño con los archivos de bloqueo. Quizás alguien que sepa más podría indicarme la dirección correcta. En el proceso de intentar llegar a una construcción funcional mínima, básicamente me reduje a una instalación de Gatsby de "hola mundo" y todavía no funcionaba, lo cual era realmente extraño.

Donde se volvió aún más extraño fue que el verdadero gatsby-starter-hello-world funciona y funciona bien en mi computadora. PERO ... si elimino el archivo de bloqueo y obtengo hilo para reconstruir un nuevo archivo de bloqueo, la compilación comienza a fallar, se cuelga en la fuente y transforma los nodos. Podría obtener mi implementación simplificada y mínima para compilar si copiara el archivo de bloqueo de "hello-world" y usara esto. Entonces, mi teoría actual es que hay algún tipo de problema de versión en mis archivos de bloqueo que está causando este problema, pero estoy atascado aquí.

También eliminé todas mis instalaciones de homebrew y reinstalé node, yarn, git, etc. Solo para asegurarme de que no fuera un asunto divertido allí.

Gracias @ehowey por plantear esto .... Pensé que era solo yo porque es bastante intermitente (pero sucede más del 50% de las veces). Hice lo mismo que tú para intentar depurar la situación. Cuando me quedo con ⠙ source and transform nodes , generalmente significa tener que matar mi terminal.

Si encuentro algo, te lo haré saber. Y también miraré este hilo.

@georgiee - gracias por la --inspect info. Voy a ver si puedo hacer que la depuración de nodos funcione con WebStorm.

También me gusta tu idea de una reproducción mínima. Pero eso llevará tiempo mientras entiendo a Gatsby un poco más profundamente.

Actualmente está pendiente de "generar y transformar nodos". En raras ocasiones, lo convierte en createPagesStatefully y se cuelga allí. De lo contrario, se construye normalmente.

Actualmente estoy enfrentando el mismo problema después de hacer una "actualización de hilo" para solucionar una dependencia vulnerable. Aquí está mi configuración:

Sistema:
SO: macOS 10.15
CPU: (4) CPU x64 Intel (R) Core (TM) i7-7567U a 3,50 GHz
Shell: 5.7.1 - / bin / zsh
Binarios:
Nodo: 12.8.1 - / usr / local / bin / node
Hilado: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
Idiomas:
Python: 2.7.16 - / usr / local / bin / python
Navegadores:
Cromo: 76.0.3809.132
Firefox: 68.0.2
Safari: 13.0
npm Paquetes:
gatsby: ^ 2.13.42 => 2.14.7
imagen-de-fondo-de-gatsby: ^ 0.8.3 => 0.8.6
imagen-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-casco: ^ 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
tipografía-plugin-gatsby: ^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts: ^ 1.1.0 => 1.1.0
gatsby-observación-imágenes: ^ 3.1.10 => 3.1.19
gatsby-observación-imágenes-relativas-v2: ^ 0.1.5 => 0.1.5
iframe-respuesta-comentario-gatsby: ^ 2.2.5 => 2.2.10
gatsby-source-filesystem: ^ 2.1.6 => 2.1.18
comentario-del-transformador-de-gatsby: ^ 2.6.12 => 2.6.19
gatsby-transformer-sharp: ^ 2.2.5 => 2.2.12

Actualmente estoy enfrentando el mismo problema después de hacer una "actualización de hilo" para solucionar una dependencia vulnerable. Aquí está mi configuración:

Actualización: me las arreglo para arreglar las cosas restaurando mi antiguo archivo "yarn.lock".

@ hbthen3rd

Actualización: me las arreglo para arreglar las cosas restaurando mi antiguo archivo "yarn.lock".

Mi experiencia es que el problema puede desaparecer sin una razón clara y volver más tarde. Es posible que el problema vuelva a aparecer a pesar de restaurar yarn.lock. Que nos mantengais.

Aquí hay una reproducción mínima usando gatsby-starter-hello-world:

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

El archivo de bloqueo actual incluido en el repositorio es el que me falla. También he incluido copias en el repositorio de yarn-working.lock y yarn-notworking.lock . Con suerte, eso facilitará la resolución de problemas.

Mi entorno actual:

Sistema:
SO: macOS High Sierra 10.13.6
CPU: (2) x64 Intel (R) Core (TM) 2 Duo CPU P8600 a 2,40 GHz
Shell: 3.2.57 - / bin / bash
Binarios:
Nodo: 10.16.3 - / usr / local / bin / node
Hilado: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
Idiomas:
Python: 2.7.10 - / usr / bin / python
Navegadores:
Cromo: 76.0.3809.132
Firefox: 67.0.2
Safari: 12.1.2
npm Paquetes:
gatsby: ^ 2.13.73 => 2.15.0
npmGlobalPackages:
gatsby-cli: 2.7.40

Estoy experimentando el mismo problema.

Alguna dirección que he encontrado:

1. La degradación de gatsby-plugin-sitemap de 2.2.9 a 2.2.6 resolvió el problema con yarn develop .

   • Es extraño porque gatsby-plugin-sitemap no debería afectar la compilación de desarrollo.

2. yarn build todavía no funciona, pero cuando elimino gatsby-plugin-sitemap mi configuración, yarn build funciona de nuevo.

@sharvit Puedo informar que esto no funcionó en mi caso. Me alegro de que lo haya solucionado, creo que tiene algo que ver en última instancia con los archivos de bloqueo y algún problema de versión extraño en las entrañas del archivo de bloqueo.

Me las arreglé para volver a una compilación funcional, la mayoría de las veces, tal vez 8/10 veces volviendo a un archivo de bloqueo antiguo y haciendo algo de copiar y pegar. Ahora también puedo CTRL + C para forzar el cierre de la compilación si está bloqueado, lo que no pude hacer en un momento de este proceso. No sé qué lo soluciona en el archivo de bloqueo, pero creo que las pistas están en el repositorio que publiqué anteriormente con dos copias de un archivo de bloqueo, una que funciona y otra que no. Esta es una extraña bestia de error. Por lo general, en la tierra de las computadoras, las cosas funcionan o no funcionan.

@steinitz ¿Tuviste suerte? Tuve lo que mencionaste. Parecía mejorar, bastante bueno pero no perfecto y ahora está fallando casi todas las veces. Bastante frustrante.

@ehowey

Como puede imaginar, debido a la naturaleza intermitente de este problema, dudo en informar. He aquí un ejemplo de ello:

Después de eliminar el directorio node_modules, eliminar yarn.lock y luego ejecutar
npx yarn-upgrade-all
y
yarn install
todo estuvo bien.

Entonces, justo ahora, en respuesta a su mensaje, intenté
yarn start
Resultado: se cuelga de nuevo en
source and transform nodes

Supongo que hay dos cosas sensatas que hacer:

1. siga el consejo de @georgiee para que la depuración de Webstorm funcione con
   node --inspect y ver si puedo detectar algún problema obvio
2. deja a Gatsby a un lado por un tiempo para ver si alguna persona inteligente resuelve el problema

Actualizar:

ctl-C hizo el proceso atascado anterior (que no solía detener el proceso atascado que era doblemente molesto).
Entonces yarn start se atascó en createPagesStatefully .
ctl-C de nuevo, otro yarn start - atascado en source and transform nodes
ctl-C una vez más (por el placer de hacerlo) - esta vez yarn start funcionó y se está ejecutando

No sé qué hacer con eso, pero ahí está.

Esto es similar a lo que estoy viendo, esta noche parece peor, tal vez construir con éxito 1/10 de veces o menos. Desde una perspectiva de programación / codificación, este es un comportamiento muy extraño. Como anécdota, parecía estar funcionando mejor hace unos días en 2.15.1 que hoy en 2.15.6. También me pregunto qué puntos en común compartimos todos que están causando este error. ¿Puedes ejecutar el comando gatsby info --clipboard y publicarlo?

Obviamente no está muy extendido, de lo contrario habría una avalancha de informes, pero tampoco soy solo yo como pensé originalmente. Parece que todos también estamos usando hilo, lo cual es un requisito para mí ya que estoy trabajando en temas en un espacio de trabajo de hilo. Todavía puedo reproducir esto en gatsby-starter-hello-world, así que creo que es un problema de dependencia o conflicto en los archivos principales de gatsby.

@ehowey aquí está el gatsby info que solicitaste

Sistema:
SO: macOS 10.14.6
CPU: (4) CPU Intel (R) Core (TM) x64 i7-5557U a 3,10 GHz
Shell: 3.2.57 - / bin / bash
Binarios:
Nodo: 12.9.1 - / usr / local / bin / node
Hilado: 1.17.3 - / usr / local / bin / yarn
npm: 6.11.2 - / usr / local / bin / npm
Idiomas:
Python: 2.7.16 - / usr / local / bin / python
Navegadores:
Cromo: 76.0.3809.132
Firefox: 68.0.1
Safari: 12.1.2
npm Paquetes:
gatsby: ^ 2.14.3 => 2.14.7
imagen-de-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-casco: ^ 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-observación-imágenes: ^ 3.1.19 => 3.1.19
gatsby-observación-prismjs: ^ 3.3.9 => 3.3.9
gatsby-source-filesystem: ^ 2.1.18 => 2.1.18
comentario-del-transformador-gatsby: ^ 2.6.19 => 2.6.19
gatsby-transformer-sharp: ^ 2.2.12 => 2.2.12
npmGlobalPackages:
gatsby-cli: 2.7.40

Tenía el mismo problema: el sitio se construyó sin problemas en Netlify, pero se colgó en mi máquina de desarrollo con gatsby build y gatsby develop .

Después de jugar con las versiones de los paquetes, noté que revertir gatsby-plugin-sitemap de la versión 2.2.10 a 2.2.9 solucionó el problema. Curiosamente, algunas personas parecen tener problemas con 2.2.9, lo que podría significar que el problema reside en otro lugar.

Editar: Habló demasiado pronto, Gatsby todavía se cuelga en los pasos "generar y transformar nodos" y "crearPáginasStatefully", aunque con mucha menos frecuencia.

@goblindegook esto parece un patrón común con este problema en particular. Debido a que el problema aparece y desaparece, aparentemente con el clima, la hora del día, el tiempo desde el inicio ... puedes creer que algo que has hecho lo ha solucionado, solo para que vuelva a ocurrir.

Al experimentar este problema también, bajé gatsby-plugin-sitemap a 2.2.6 y eso parece haberlo solucionado

FWIW, también estoy experimentando esto, pero no utilizo ni yarn ni gatsby-plugin-sitemap .

Mi gatsby info en caso de que ayude:

  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

Para mí, limpiar el caché con gatsby clean resolvió el problema.

Todavía estoy cazando, tratando de resolver esto. Sigue siendo un problema para mí. ¿Alguien sabe si esto podría estar relacionado con el cambio de babel 7.0.0 -> 7.5.5? Este cambio sucedió en el momento en que comencé a experimentar este error y coincide con que comencé a ver problemas ... He estado tratando de que las resoluciones de hilo funcionen para vincular las versiones de babel a 7.0.0 pero no he tenido éxito con esto todavía.

Creo que puedo ofrecer algunas ideas: comencé a tener este problema cuando, a la mitad de agregar complementos a un proyecto, actualicé gatsby-cli en otra ventana de terminal. Ejecutar gatsby clean en mi proyecto funcionó.

de https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 - También veo este problema, pero gatsby clean no lo resolvió. Parece que podría ser que la impresión de CLI se cuelga, ¿por qué cambiar el tamaño del terminal lo soluciona? 🤷‍♂ 😕 ❓❗️

¡Cambiar el tamaño de la ventana de la terminal parece arreglarlo para mí! No lo he probado muy extensamente, ¿pueden otras personas que tengan este problema intentarlo también? Qué error más extraño y solución potencialmente extraña.

Estoy enfrentando exactamente el mismo problema: gatsby se atasca en "fuente y nodos de transformación" o "createPagesStatefully" a menudo, y _no_ estoy usando ningún complemento de fuente. Recientemente me encontré con la corrección de "cambiar el tamaño de la ventana de la terminal" y estoy 140% desconcertado en cuanto a cómo diablos esto lo soluciona, pero lo hace. ¡Esto parece un problema bastante serio!

@JaKXz - ¡Gracias! Esto me estaba volviendo loco. La solución parece cambiar el tamaño de la ventana del terminal en VS Code. Simplemente arrástrelo un poco hacia arriba o hacia abajo y la tarea de desarrollo avanza felizmente. Probé en un par de casos diferentes tanto hilo como npm, espacios de trabajo y no. Parecía estar funcionando en todos esos casos para mí. También parece congelarse o colgarse en createPagesStatefully más a menudo que source and transform nodes ahora para mí. Voy a dejar el problema abierto por ahora, es posible que deba solucionarlo de una manera menos "hacky" por parte de alguien con más conocimientos que yo.

@ehowey Tengo el mismo problema y mover la ventana del terminal en vscode funciona (no podía creerlo al leer este problema hasta que lo probé yo mismo).
¿Sabes si solo ocurre en VS Code?

Tengo este problema en iTerm 2, por lo que no es específico de VS Code.

Mi problema también ha estado en iTerm 2

Terminal Webstorm, Terminal Mac, iTerm

¿La solución de cambio de tamaño de la terminal funcionó para todos ustedes en diferentes entornos de desarrollo?

Por mi parte, cambiar el tamaño del terminal funcionó en iTerm y VSCode (tomó algunos intentos para reproducir el problema en iTerm)

El truco de cambiar el tamaño del terminal funciona de manera confiable para mí en iTerm 2.

Sí, cambiar el tamaño de iTerm 2 funciona perfectamente

Si el cambio de tamaño funciona, sospecho que este error está relacionado con el búfer, en algún lugar necesita stdout flush.

Esto parece un problema relacionado con el kernel + shell. Probablemente el nodo interactúe de alguna manera con su kernel y / o su shell. Solo digo esto porque parece que no puedo replicar los problemas usando Linux o Windows. Parece que no puedo encontrar ningún problema conocido, así que a) es una combinación de patrones de código exclusivos de Gatsby + la interacción con el sistema, ob) simplemente no sé la pregunta correcta para hacer todavía.

Si cambiar el tamaño de la terminal soluciona el problema, entonces podría ser un problema técnico entre el nodo y kqueue causando un bloqueo en el bucle de eventos. Cambiar el tamaño del terminal envía al proceso una señal SIGWINCH, que interrumpe el bucle de eventos, lo que lo libera y le permite continuar.

¿Puedes intentar ejecutar kill -SIGWINCH ${pid} en el proceso en ejecución cuando se congela? Debería actuar igual que cambiar el tamaño de la terminal.

También me interesa saber si esto sucede en todas las conchas. Según la información hasta ahora, esto ha fallado en bash y zsh , y este es probablemente uno de los factores comunes entre todos los emuladores de terminal. ¿Pueden probar uno o más de sh , csh , ksh , tcsh , etc ...?

Si el problema ocurre en todos los shells, entonces supongo que es la forma en que el kernel maneja el bucle de eventos del nodo. Esta también podría ser la razón por la que es un problema intermitente. Si alguna función obtiene menos tiempo de procesador (tal vez debido a la carga variable del sistema), podría bloquearse durante demasiado tiempo y tal vez el kernel intente reutilizar un nodo de eventos en alguna parte, lo que resultará en un punto muerto. No estoy muy familiarizado con los aspectos internos de la API, pero apuesto a que source and transform nodes es bastante intensivo en E / S del sistema de archivos. Eso significa que probablemente haya muchas descargas, así que quién sabe lo que realmente está sucediendo en los niveles inferiores.

Creo que sería una buena idea intentar reducir la superficie de este error. Ocurre con mayor frecuencia en source and transform nodes , parece, así que tal vez intente reducirlo a qué complemento está bloqueando. Intente agregar las siguientes líneas a 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       })));

Luego ejecute node inspect node_modules/.bin/gatsby develop . Se interrumpirá tan pronto como comience, por lo que debe presionar c cuando llegue al indicador debug> y esperar a que continúe. Cuando se rompa en esa línea debugger , escriba exec console.log(plugin) y observe lo que dice en resolve . Luego presione c para continuar. Solo haz esto hasta que cuelgue ... si cuelga.

Debido a la naturaleza del bucle de eventos, apuesto a que ni siquiera se bloqueará durante la depuración. Esas interrupciones probablemente sean suficientes para mantener el rumbo. Los errores asincrónicos pueden ser un verdadero problema para rastrearlos. Si no se cuelga mientras usa el depurador, reemplace esa línea debugger con:

reporter.log(plugin.resolve);

Con suerte, eso resultará en algo. Sería bueno ver qué complemento está causando el bloqueo. Si podemos resolver eso, es posible que podamos averiguar qué necesita ser optimizado / refactorizado para solucionar esto.

El cambio de tamaño también funciona para mí, uso zsh como mi shell VSCode.

@ Js-Brecht - Gracias por tomarse el tiempo para una respuesta tan detallada. No estaba seguro exactamente de dónde se suponía que debía ingresar kill -SIGWINCH ${pid} . No pude hacerlo durante el proceso de construcción.

Con el depurador salió el siguiente código ... más allá de mí para darle mucho sentido. De hecho, me quedé atascado en el depurador, pero .exit todavía funcionaba.

⠋ 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, usando Terminal, el cambio de tamaño funcionó para mí.

@ehowey Solo para saber que te estoy entendiendo correctamente, ¿se colgó mientras estabas en el depurador? En ese caso, me parece que gatsby-source-filesystem es el culpable, lo cual tiene sentido para mí ... especialmente debido a problemas relacionados con gatsby existentes.

Me gustaría ver si el complemento puede realizar una prueba. Si se cuelga durante la ejecución de las pruebas, creo que será una forma fácil de ver dónde está fallando. Si no, bueno ... tendré que hacer un poco de disección / depuración, lo cual será difícil para mí, ya que no tengo MacOS.

¿Puedes descargar el repositorio principal de gatsby y ejecutar las pruebas 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'

Además, ¿está haciendo todo esto con su repositorio de reproducción mínima? Veo que gatsby-plugin-mdx se ejecutó dos veces, por lo que me dice que no es un repositorio básico. En un mundo perfecto, no debería importar, pero creo que sería mejor ejecutar una configuración lo más simple posible. Si no puede hacer que falle de manera confiable con el repositorio mínimo, utilice el que falle de manera más consistente (en el mismo lugar, cada vez (o cerca de))

😉

kill -SIGWINCH ${pid} debe ejecutarse desde otra instancia de shell. Cuando la compilación se cuelgue, abra otra ventana / pestaña de terminal y ejecute el comando desde allí. Este pequeño fragmento debería funcionar:

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

Si hay errores, intente ejecutar los comandos por separado:

# 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 llega con las manos vacías después de ejecutar las pruebas, creo que será útil tener un volcado del núcleo, para que podamos obtener un seguimiento de la pila. Pero un paso a la vez.

@ Js-Brecht Perdón por las respuestas más lentas ... esto es realmente solo un pasatiempo secundario que hago en el tiempo libre por las noches.

Así que ejecuté lo mismo dentro del motor de arranque de gatsby hello world, lo más básico posible. Lo siento, lo ejecuté antes en mi espacio de trabajo principal en un proyecto con el que había tenido problemas. Sin embargo, lo he replicado previamente en principiantes, así que no creo que se relacione con un complemento, sino con algo en el núcleo de gatsby.

Se cuelga de los nodos de origen y transformación, lo que me da el siguiente resultado:

< 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

Aquí hay un volcado del comando gatsby info en caso de que sea útil:

  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

Como nota al margen, cuando uso su comando de depuración, se cuelga en los nodos de origen y transformación. Cuando utilizo gatsby development, la mayoría de las veces se cuelga en createPagesStatefully ahora para mí. Lo siento, sé que esto es realmente extraño. Para ser honesto, no estoy seguro de cuánto trabajo vale de tu parte. El truco de cambiar el tamaño de la ventana de la terminal funciona siempre para mí y para los demás. Es una solución pirata, pero no debe afectar a muchos usuarios, de lo contrario, los problemas se inundarían.

Esto también ha comenzado a suceder aquí. El truco _resize the terminal_ lo resuelve; ¡muy raro!

+1 No funciona en iTerm2, pero funciona en Terminal 🤷‍♂️

@ehowey La mayor parte de lo que sucede durante la compilación está definido por un complemento u otro. Gatsby se envía con ellos como dependencias; Supongo que podrían considerarse complementos básicos. El núcleo de Gatsby expone una API, que busca los puntos finales definidos en los complementos y les pasa una serie de argumentos que incluyen acciones / objetos que se definen en el núcleo. Entonces, sí, lo que está sucediendo podría estar sucediendo en el núcleo, pero primero tiene que llamar a un complemento, y esos complementos definen un contexto específico para la API. Estoy tratando de determinar el contexto que está provocando que la compilación se cuelgue, y también necesito verificar que el problema no esté ocurriendo en el complemento.

¿Puedo conseguir que cambie estas líneas?

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

Ejecute esto y copie / pegue todo el resultado (incluso podría adjuntarlo a su respuesta como un archivo .txt ). Será considerablemente más detallado y mucha de la información probablemente será innecesaria, pero 🤷‍♂.

Una vez hecho esto, me gustaría ver si aumentar el grupo de subprocesos del nodo hace una diferencia. He notado otros problemas que mencionan lo mismo o problemas similares. La mayoría de las veces ocurren en source and transform , y algunos hablan de que esa etapa tarda una eternidad o que se cierra por completo. Entonces, quiero ver si hay algún tipo de punto muerto en el sistema de archivos io ... el acceso al sistema de archivos asíncrono se descarga por nodo a diferentes subprocesos y, de forma predeterminada, el nodo solo tiene un grupo de 4 subprocesos para el espacio de usuario. Si se llenan y necesita descargar más, las tareas se pondrán en cola en el bucle de eventos principal, esperando un hilo. Esto podría, potencialmente, detener todo el programa ... hasta que haya un hilo disponible. Gatsby mantiene un caché en el sistema de archivos, por lo que tal vez haya una colisión en algún lugar, y si ocurre algún tipo de interbloqueo, entonces tal vez los hilos estén esperando un tiempo de espera / interrupción antes de continuar, y si hay docenas (o cientos, incluso) de los eventos de acceso al sistema de archivos, todos podrían estar esperando el mismo tiempo de espera y haciendo que todo se acumule. Puede ver que esto podría hacer que los tiempos de espera crezcan con bastante rapidez.

Aumentar el tamaño de la piscina podría ayudar a aliviar parte del tráfico ... o podría suceder de la misma manera, solo con más hilos 😆.
Prueba el siguiente comando:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht Cambiar el tamaño del grupo de subprocesos no pareció hacer mucha diferencia.
Obtengo el siguiente resultado del comando estándar gatsby develop con los cambios que mencionaste anteriormente. Todavía en el arranque básico de gatsby hello-world.

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

Este es un ejemplo en el que se cuelga de createPagesStatefully . Lo conseguí para continuar la compilación cambiando el tamaño de la ventana de la terminal. ¿Cuál es internal-data-bridge cualquier posibilidad de que pueda ser el culpable de alguna manera? Eso estaba incluido en los dos comandos que me ha pedido que ejecute hasta ahora.

¿Puedes mostrar en qué línea colgó?

createPagesStatefully dev-404-page

No estoy 100% seguro de si la parte dev-404-page estaba allí, pero se colgó en la primera instancia de createPagesStatefully

Gracias. Me gustaría probar algunos cambios más ahora, si no le importa.

Actualice las líneas indicadas en los siguientes archivos:

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

Tengo la sospecha de que chokidar podría tener la culpa aquí. Se actualizó a v3.x hace aproximadamente un mes, y parece que comenzaron a usar fsevents , o hicieron algo que causó un comportamiento errado en relación con fsevents . Tienen algunos problemas abiertos similares a los que enfrentamos aquí, con el nodo colgado al usar chokidar.watch() . Esto parece encajar, ya que está localizado en MacOS debido a que fsevents es un proceso de Mac, y la compilación parece estar fallando en los módulos donde se está utilizando, o en los módulos que están escribiendo / procesando archivos. que probablemente estén siendo observados.

chokidar.watch() existe en gatsby-source-filesystem , y ahí es donde estaba fallando con su otro repositorio, @ehowey; sin mencionar, gatsby-source-filesystem no se está llamando en su repositorio mínimo, lo que explica por qué está pasando de source and transform . Hay instancias de chokidar antes de internal-data-bridge , pero creo que en ubicaciones que no afectan la compilación (por ejemplo, query-watcher ). Sin embargo, creo que internal-data-bridge es la razón por la que se bloqueó mientras se ejecutaba el depurador; y en una ejecución directa, probablemente estaba afectando las etapas posteriores de la compilación.

Avíseme si esto soluciona los problemas, o incluso si llega más lejos de lo que ha sido. :dedos cruzados:

@ Js-Brecht ¡Estás llegando a alguna parte! Corrí gatsby develop probablemente 15 veces. Nunca colgó en source and transform nodes o createPagesStatefully pero parecía colgar, tal vez 2/10 veces, en start webpack server . También podría agregar esto junto con el truco de cambiar el tamaño de la terminal. ¿Alguna posibilidad de que se haya perdido una instancia de chokidar / fsevents que se relacione con start webpack server ?

Como nota al margen, también parecía moverse a través de los pasos del proceso de desarrollo mucho más rápido que antes, si eso tiene algo que ver con eso.

Es realmente bueno escuchar eso. Dejé una instancia de chokidar, a propósito, y es justo después de que finaliza el arranque e inicia el servidor. Está en node_modules/gatsby/dist/commands/develop.js hacia el final de la función startServer() . No estoy en una computadora en este momento, o te daría una diferencia.

Puede encontrar la línea exacta haciendo:

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

Estaba bastante seguro de que si esto arreglaba el bootstrap, todavía tendría que colgarse en el servidor. Avíseme si cambiar eso hace que funcione de manera confiable, enviaré un PR y me encargaré de informar a la gente.

De hecho, no me sorprende que lo haga funcionar más rápido. La compilación de un proyecto básico generalmente me lleva tal vez un segundo, y vi algunos tiempos de ejecución largos y locos para ciertas etapas en su salida de depuración. Se supone que fsevents acelera las cosas y quita gran parte de la carga de la CPU, pero en su lugar está pasando algo gracioso que hace que se atasque.

@ Js-Brecht Me quito el sombrero ante ti. No tengo idea de cómo sacaste ese conejo de un sombrero y arreglaste un error tan extraño desde la distancia, ¡pero buen trabajo! Esperaré a que la diferencia haga cambios en develop.js ya que no quiero cambiar lo incorrecto, pero sospecho que eso lo solucionará, ya que estaba colgando en el último paso cuando inicia el servidor un par de veces.

Aquí está la diferencia:

node_modules/gatsby/dist/commands/develop.js

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

Realmente agradezco su ayuda, ejecutando todas estas pruebas. Esto ha sido complicado, pero ha sido una oportunidad para profundizar en los aspectos internos de MacOS, y siempre disfruto aprendiendo cosas nuevas: mild_smiling_face:

Hágame saber como va por favor; aún no completamente fuera de peligro: sweat_ smile :.

¡Trabajos! Acabo de ejecutar gatsby develop 10+ veces y funcionó a la perfección. Gracias por su ayuda para investigar esto. ¡Esperamos que esto sea una mejora para el grupo de nosotros que experimentamos esto!

¡Excelente! Aquí en un rato, cuando tenga un par de minutos, armaré un PR. Una vez hecho esto, podrá usar gatsby-dev-cli con mi repositorio para que tenga un entorno de desarrollo en funcionamiento hasta que se publique un parche (si no está familiarizado con gatsby-dev-cli , puedo ayuda). Podría intentar reclutarlo para probar los cambios de todos modos, ya que no tengo el sistema operativo correcto ... lo mismo ocurre con todos los demás en este hilo que experimentan este problema.

Volveré a publicar aquí cuando esté listo.

Encontré otro problema separado que también causa este síntoma: https://github.com/gatsbyjs/gatsby/issues/17935

Si alguien está usando LokiJS y cambiar el tamaño del terminal no lo soluciona, es muy probable que sea el problema que encontré.

Hola chicos, @ehowey , por favor revisen PR # 17938. Si alguien está dispuesto a realizar la prueba, hágalo y escriba en el PR.

Puede enganchar mi repositorio y usarlo como su fuente gatsby en su sitio usando gatsby-dev-cli . Primero, necesitas gatsby-dev-cli

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

Luego, simplemente clone el repositorio y arranque.

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

Luego, vaya al sitio en el que desea usar el repositorio y ejecute gatsby-dev

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

en mi caso, estoy usando OSX e IntelliJ, tuve que:

• Cerrar el proyecto en IntelliJ
• Vuelve a intentarlo ( npm start )
• y reabrir el proyecto en Intellij
  Supongo que el problema está relacionado con los archivos de indexación de IntelliJ

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

¿Alguno de ustedes está dispuesto a probar el número 17938?

Debería poder echar un vistazo más tarde esta noche cuando esté en casa. ¡Agradezco a todos por su trabajo en esto!
El 1 de octubre de 2019, 10:23 a.m. -0600, Jeremy Albright [email protected] , escribió:

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel
¿Alguno de ustedes está dispuesto a probar el número 17938?
-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

¿Alguna actualización sobre la solución para esto? Se está congelando en la fuente y transforma los nodos para mí y mi amigo también después de probar [Firebase Source] Fetching data for ...

Desafortunadamente, cambiar el tamaño de la terminal no parece solucionarlo para nosotros

@ rishabhaggarwal2 Hay un problema similar que parece que podría ser lo que está experimentando, donde se bloqueará mientras se recuperan datos de una fuente en línea. ¿Puedes intentar usar GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Viendo esto también. No se puede ejecutar gatsby develop localmente en absoluto en el inicio de lumen. Sigue pendiente de createPageStatefully o source and transform nodes

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

Si alguien más encuentra este problema, intente

CHOKIDAR_USEPOLLING=1 gatsby develop

Eso debería deshabilitar fsevents en MacOS, que parece ser una solución confiable.

@ Js-Brecht Confirmo que parece arreglarlo de forma más permanente que las otras soluciones mencionadas aquí. Gracias por compartir.

@steinitz dices “más” permanentemente. ¿Quiere decir que todavía sucede cuando usa ese interruptor?

@ Js-Brecht No, siento que no quede claro.

Me refería al hecho de que otras soluciones, incluida la mía, parecían funcionar durante un tiempo, pero el problema volvió. Con su solución, lo provoqué haciendo cambios y volviendo a ejecutar gatsby development (con su mejora), pero la compilación continúa funcionando.

Dicho esto, este ha sido un viaje en montaña rusa, así que sigo preparado emocionalmente: sonríe: para que el problema vuelva.

Para ser claros: hasta ahora todo bien.

Vaya, actualización: Relancé WebStorm para una prueba final antes de publicar esto y ahora está colgado en source and transform nodes en la terminal de WebStorm.

Si alguien más encuentra este problema, intente

CHOKIDAR_USEPOLLING=1 gatsby develop

Eso debería deshabilitar fsevents en MacOS, que parece ser una solución confiable.

@ Js-Brecht Estoy usando ubutu 18.04 y me encuentro con el mismo problema ocasionalmente. ¿Hay alguna sugerencia para mi sistema operativo? ¿Podría proporcionar algunos detalles sobre las posibles causas de este problema?

Esto se ha resuelto gracias al trabajo diligente de @ Js-Brecht y @RomanHotsiy. Fue un problema ascendente en fsevents, mucho más allá de lo que podría haber descubierto por mi cuenta, y debería solucionarse en futuras actualizaciones una vez que estos cambios se implementen y migren de fsevents a gatsby. Por ahora, una solución alternativa confiable es cambiar el tamaño de la ventana de la terminal, hay una manera de solucionar esto en su repositorio, que se analiza aquí: https://github.com/gatsbyjs/gatsby/pull/17938, sin embargo, tendría que rehacer esto arregle después de cualquier cambio en su carpeta node_modules y puede que no valga la pena el trabajo dependiendo de la frecuencia con que actualice las versiones de su paquete.

Dejaré el problema abierto hasta que la solución migre corriente abajo al propio gatsby.

@ Boty22 Ubuntu no usa fsevents , por lo que probablemente sea algo diferente. Se han encontrado algunos problemas al recuperar datos de una ubicación remota; Consulte los números 6654 y 17940 para obtener algunos detalles sobre cómo solucionar problemas de concurrencia.

Pregunta rápida: ¿ayuda cambiar el tamaño de su terminal? Si es así, podría ser _algo_ similar a este problema.

@ Js-Brecht cambiar el tamaño de la terminal no ayuda para Ubuntu. Estoy recuperando datos de una tabla AirTable usando el complemento gatsby-source-airtable BTW

Ese podría ser el problema. Mira este comentario . Si eso no funciona, sería mejor abrir un nuevo ticket

@steinitz lo siento, me perdí tu comentario. ¿Puedes probar la solución descrita en el # 17938? Más específicamente, aquí y aquí . Si no funciona, probablemente haya más en su caso.

No he tenido ningún problema con CHOKIDAR_USEPOLLING=1 gatsby develop desde que se mencionó.

Gracias por la solución @ Js-Brecht

También veo esto con 2.15.28 cuando hago gatsby build. ¿Tengo que detener el desarrollo de gatsby en la otra terminal? Está sucediendo de manera intermitente

Ocurrió de nuevo sin que el servidor de desarrollo se estuviera ejecutando. Sin embargo, tengo un blog simple siguiendo el tutorial del blog.

Parece ser casi cualquier otra carrera. Estoy en una Mac por cierto

@canvaspixels, ¿cambiar el tamaño de la ventana de la terminal despega tu compilación? Si es así, intente esto y avísenos si le ayudó https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991

@RomanHotsiy ¡ eso realmente lo ordena! ¡Gracias!

Hola a todos, se ha publicado la versión parcheada de fsevents . Debería poder simplemente eliminar su archivo yarn.lock y ejecutar yarn nuevamente. Cada una de sus dependencias debería recoger automáticamente [email protected] , lo que debería resolver el problema.

Tenga cuidado: eliminar todo su archivo yarn.lock también puede hacer que se actualicen otros paquetes.

Otra opción más precisa si está usando yarn es eliminar solo las líneas relacionadas con fsevents en yarn.lock y volver a ejecutar yarn . Esto hará que solo se actualice el paquete afectado. Entonces, por ejemplo, eliminé las siguientes líneas:

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

Otra forma de hacer esto es usar la función resolutions de Yarn (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/). Al agregar lo siguiente a su package.json y luego ejecutar yarn , también actualizará las dependencias transitivas y actualizará su archivo yarn.lock :

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

Una vez que haya hecho esto y su archivo de bloqueo esté actualizado, puede eliminar la propiedad resolutions de package.json nuevamente.

Editar: eliminó la versión anterior incorrecta de las instrucciones.

También puede ejecutar yarn upgrade chokidar@latest . Eso debería reconstruir el archivo de bloqueo con la versión correcta de fsevents, sin tocar nada más

Oh espera. Eso es solo si tiene chokidar como una dependencia directa 🙄. Olvidó. @karlhorky tiene razón

Estoy usando npm . Eliminar node_modules , ejecutar npm i --save [email protected] y luego npm i sirvió. Tomó 19 años para iniciar y estoy usando gatsby-lumen-starter como base.

- Editar:

De hecho, terminé en lo que estaba trabajando, lo empujé a Netlify y no se pudo construir por completo debido a fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ).

Cambié a yarn y tuve el mismo problema, así que eliminé el hilo fsevents completo, y ahora local y netlify funcionan ...

Tengo el mismo problema y no pude rastrear el motivo. Esto me pasó tanto en mac como en pc. Podría intentar relacionar esto con la velocidad de Internet, sin embargo, esto también me sucedió cuando estaba conectado a una red de alta velocidad. Lo que parece estar funcionando para mí en este momento es agregar esto en mi env

GATSBY_CONCURRENT_DOWNLOAD=5

y ejecutar usando --v8-pool-size=128

En mi caso, parece ser el indicador de mi firewall en osx. Si soy lo suficientemente rápido para permitir o denegar conexiones provenientes del exterior, lo haré sin problemas. El problema es que el cuadro de diálogo emergente aparece durante una fracción de segundo y desaparece cuando Gatsby continúa y luego falla al seguir uno de los muchos pasos mencionados anteriormente.
Opciones:

• deshabilitar el firewall (no tener eso)
• lista blanca de Gatsby (no es coherente en todos los proyectos y actualizaciones)
• encontrar una manera de detenerse en el aviso hasta que el usuario seleccione la opción
• dirección de enlace predeterminada a localhost (no debería requerir un mensaje para aceptar conexiones entrantes).

@thomasthep La dirección de enlace predeterminada para el servidor de desarrollo ya es localhost. Ni siquiera escucha conexiones externas a menos que le indique que use su dirección IP externa (o 0.0.0.0). E incluso entonces, no inicia el servidor de desarrollo hasta que finaliza el arranque / compilación. Si es el bootstrap lo que está causando el aviso del firewall, entonces tendría más que ver con los complementos que está usando, porque Gatsby no llega a Internet en su estado predeterminado.

Ni siquiera debería haber conexiones "provenientes del exterior", en términos generales; Incluso cuando un complemento recopila información de una fuente externa, la conexión se origina en su host local, no en la fuente externa, y eso generalmente es aceptado como una "conexión establecida" por la mayoría de los firewalls, en mi experiencia, ya que la mayoría de los firewalls están configurados para aceptar cualquier conexión saliente.

Podría ver que esto sucede si su firewall está configurado para bloquear procesos, en lugar de solo conexiones. En ese caso, sería Nodo el que debería incluirse en la lista blanca.

Necesitaría más información para comprender realmente por qué le está sucediendo eso. Sin embargo, probablemente sería más efectivo abrir un nuevo ticket. Este tenía que ver con fsevents en MacOS que causaban problemas, y eso se ha solucionado, por lo que está cerrado ahora. Todo lo que no esté relacionado con fsevents realmente debería tener su propio problema, para obtener la atención que merece.

Para el registro, esto también puede suceder si tiene su servidor GraphQL ejecutándose en modo de depuración y se detiene en un punto de interrupción.

Para el registro: esto comenzó a sucederme cuando agregué gatsby-source-s3-image y el cubo s3 alcanzó más de 100 imágenes. Pasa por las 145 imágenes en la etapa source and transform nodes y luego se queda ahí para siempre. Todavía está sucediendo, probé las correcciones anteriores. Afortunadamente, funciona después de 5-6 intentos, por lo que no estoy bloqueado.

Extrañamente, cambiar el tamaño de la ventana de la terminal funcionó para mí

Para mí, limitar las descargas simultáneas como se describe aquí parece ayudar.

Agregué la siguiente línea a mi archivo .env. El valor predeterminado es 200.
GATSBY_CONCURRENT_DOWNLOAD=50

No estoy seguro de si resuelve su problema, pero tal vez ayude a alguien :)

@ rishabhaggarwal2 Hay un problema similar que parece que podría ser lo que está experimentando, donde se bloqueará mientras se recuperan datos de una fuente en línea. ¿Puedes intentar usar GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Gracias, esto me lo arregló. Como estaba sacando una tonelada de contenido de un sitio web de terceros, seguía pendiente de descargar el contenido. (97% - tan cerca pero tan lejos)