Gatsby: [bug fsevents] Preso em "source and transform nodes" / "createPagesStatefully" no MacOS

Atualizado - testei comentar o arquivo gatsby-node.js e a compilação progrediu em uma ocasião, mas tentei novamente e fiz isso e ficou preso no mesmo lugar novamente.

Existe alguma chance de que isso seja devido ao meu antigo computador, Macbook Pro 2010 (atualizado para 8 GB de RAM e um SSD), ainda não me impediu, mas sei que seus dias são limitados. Este é um hobby para mim e eu tenho filhos pequenos, então os dólares não estão lá para gastar em um novo computador, já que este funcionou bem com o Ram e o SSD atualizados.

Tentei reverter para o gatsby 2.13.52, que foi a última versão em que estava estável, também tentei reverter para reagir a 16.8.6.

Curiosamente, uma vez que o construí com sucesso, quando reverti a reação para 16.8.6, mas depois dessa primeira vez, ele desligou no mesmo local, o que é um comportamento muito estranho para mim.

Eu também posso, raramente, por nenhuma razão que eu consiga discernir para construí-lo bem. Não parece haver rima ou razão para quando isso acontecer. Passei algumas horas procurando padrões ou erros que possam estar causando isso, mas não encontrei nada. Eu analisei https://github.com/gatsbyjs/gatsby/issues/6654 e tentei alguns dos itens lá sem sucesso.

Este é um dos bugs mais estranhos que já encontrei, porque o comportamento parece mudar sem que haja mudança perceptível no código. Em alguns casos, a construção trava nos nós de origem e de transformação (60% do tempo), em alguns casos ela trava em Criar páginas com estado (20%), em alguns casos ela é construída com sucesso (20%). Eu fiz com que ele exibisse todos os três desses comportamentos sem alterar uma linha de código.

Também repliquei esse comportamento no blog gatsby-starter, o que é realmente estranho. Mais uma vez, isso me faz pensar que este é um problema localmente meu. Curiosamente, ele só fica em createPagesStatefully .

Agora estou começando a pensar que tem algo a ver com uma biblioteca que foi atualizada pelo homebrew automaticamente - qual eu não tenho ideia, mas é a única coisa que consigo pensar que não testei.

Aqui está uma lista das coisas que tentei até agora:

• Alterando as versões do nó, tentei 12, 10 e 8

• Revertendo a um ponto anterior em meu histórico de commits que estava funcionando - ainda falha agora.

• Comentando plug-ins e áreas do gatsby-config

• Comentando o conteúdo do meu gatsby-node.js

• Teste novamente no Netlify, ainda construído com sucesso, o que me faz pensar que deve ter algo a ver com o meu computador.

• Excluindo as 4 páginas em meu diretório src / pages e colocando um arquivo index.mdx muito básico

• Excluindo todos os arquivos node_module e lock, reinstalando

• Reiniciando o computador

• Criando um novo espaço de trabalho de fios com novos clones do tema / iniciador do Github.

• Testando gatsby-starter-blog, comportamento semelhante, mas fica pendurado em createPagesStatefully

Olá,

Posso fazer pouco além de confirmar que estou vendo esse problema em vários iniciantes do Gatsby. E, como você assinalou, às vezes ele simplesmente decide construir ou parar de construir, pendurado em "nós de origem e transformação" ou em createPagesStatefully.

Muito frustrante e levando a tentar as mais ultrajantes tentativas de consertá-lo.

Não presenciei esse problema, mas isso parece estranho e eu realmente gostaria de saber o motivo desse comportamento de sua parte.

Preparação
Você deve tentar usar o depurador de nó para chegar à raiz do problema. Uma tarefa em seu package.json seria assim. Se você estiver usando VSCode, você pode ativar o "Auto Attach" para usar o depurador interno junto com esta tarefa (certifique-se de usar o terminal interno para esta finalidade)

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

Obviamente, a depuração funcionará com qualquer IDE, apenas certifique-se de conectar o depurador corretamente.

1. Variante: Reprodução Mínima
Você mencionou createPagesStatefully como a origem do problema. Se você tiver certeza de que essa é a origem do problema, talvez você possa criar um projeto bem pequeno para reproduzi-lo. Esqueça todos os iniciadores, apenas use gatsby diretamente e use createPagesStatefully até gatsby-node.js com alguns exemplos que imitam as coisas que seus iniciantes estão fazendo. Em seguida, inicie o gatsby e depure-o por meio de inspeção de nó.

Dessa forma, você pode descobrir onde ele fica pendurado.

2. Alternativa: Dentro de seu projeto / iniciador
Você pode, é claro, tentar depurar o problema dentro de seu projeto com a mesma técnica. Mas talvez você tenha vários problemas que se acumulam e confundem sua visão sobre a causa dos problemas. Então, eu sempre tentaria obter uma reprodução mínima antes de começar a depurar.

Boa sorte.

Então ... eu tive um comportamento estranho com os arquivos de bloqueio. Talvez alguém que saiba mais possa me indicar a direção certa. No processo de tentar obter uma construção mínima funcional, basicamente reduzi a instalação de Gatsby "hello world" e ainda não estava funcionando, o que era muito estranho.

O que ficou ainda mais estranho foi que o gatsby-starter-hello-world real funciona e constrói bem no meu computador. MAS ... se eu deletar o arquivo de bloqueio e obter yarn para reconstruir um novo arquivo de bloqueio, a construção começa a falhar, travando nos nós de origem e de transformação. Eu poderia ter minha implementação reduzida e mínima para construir se copiasse o arquivo de bloqueio de "hello-world" e usasse isso. Minha teoria atual é que há algum tipo de problema de versão em meus arquivos de bloqueio que está causando esse problema, mas estou preso aqui.

Eu também apaguei todas as minhas instalações de homebrew e reinstalei node, yarn, git, etc. Só para ter certeza de que não havia nada de engraçado ali.

Obrigado @ehowey por levantar isso ... Achei que fosse só eu porque é bastante intermitente (mas acontece mais de 50% das vezes). Fiz o mesmo que você para tentar depurar a situação. Quando eu penduro em ⠙ source and transform nodes , geralmente significa ter que matar meu terminal.

Se eu encontrar algo, avisarei você. E eu vou assistir este tópico também.

@georgiee - obrigado pela --inspect info. Vou ver se consigo fazer a depuração de nós funcionar com o WebStorm.

Também gosto da sua ideia de uma reprodução mínima. Mas isso vai demorar enquanto eu entendo Gatsby um pouco mais profundamente.

Atualmente está pendurado em "nós de origem e transformação". Raramente, ele criaPagesStatefully e fica pendurado lá. Caso contrário, ele constrói normalmente.

Atualmente, estou enfrentando o mesmo problema depois de fazer "atualização de fios" para corrigir uma dependência vulnerável. Aqui está minha configuração:

Sistema:
SO: macOS 10.15
CPU: (4) x64 Intel (R) Core (TM) i7-7567U CPU @ 3,50 GHz
Shell: 5.7.1 - / bin / zsh
Binários:
Nó: 12.8.1 - / usr / local / bin / node
Fio: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
Línguas:
Python: 2.7.16 - / usr / local / bin / python
Navegadores:
Chrome: 76.0.3809.132
Firefox: 68.0.2
Safari: 13,0
npmPacotes:
gatsby: ^ 2.13.42 => 2.14.7
gatsby-background-image: ^ 0.8.3 => 0.8.6
imagem 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-helmet: ^ 3.1.2 => 3.1.5
gatsby-plugin-react-svg: ^ 2.1.1 => 2.1.2
gatsby-plugin-sass: ^ 2.1.3 => 2.1.12
gatsby-plugin-sharp: ^ 2.2.9 => 2.2.18
tipografia-plugin-gatsby: ^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts: ^ 1.1.0 => 1.1.0
imagens-observação-gatsby: ^ 3.1.10 => 3.1.19
gatsby-observação-imagens-relativas-v2: ^ 0.1.5 => 0.1.5
iframe responsivo-observação-gatsby: ^ 2.2.5 => 2.2.10
gatsby-source-filesystem: ^ 2.1.6 => 2.1.18
observação de transformador de gatsby: ^ 2.6.12 => 2.6.19
gatsby-transformador-sharp: ^ 2.2.5 => 2.2.12

Atualmente, estou enfrentando o mesmo problema depois de fazer "atualização de fios" para corrigir uma dependência vulnerável. Aqui está minha configuração:

Atualização: eu consigo consertar as coisas restaurando meu antigo arquivo "yarn.lock".

@ hbthen3rd

Atualização: eu consigo consertar as coisas restaurando meu antigo arquivo "yarn.lock".

Minha experiência é que o problema pode desaparecer sem um motivo claro, apenas para retornar mais tarde. Você pode encontrar o problema retornando, apesar de restaurar yarn.lock. Mantenha-nos informados.

Aqui está uma reprodução mínima usando gatsby-starter-hello-world:

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

O arquivo de bloqueio atual incluído no repo é o que está falhando para mim. Também incluí cópias no repositório de yarn-working.lock e yarn-notworking.lock . Esperançosamente, isso torna mais fácil para alguém solucionar o problema.

Meu ambiente atual:

Sistema:
SO: macOS High Sierra 10.13.6
CPU: (2) x64 Intel (R) Core (TM) 2 Duo CPU P8600 @ 2,40 GHz
Shell: 3.2.57 - / bin / bash
Binários:
Nó: 10.16.3 - / usr / local / bin / node
Fio: 1.17.3 - / usr / local / bin / yarn
npm: 6.10.3 - / usr / local / bin / npm
Línguas:
Python: 2.7.10 - / usr / bin / python
Navegadores:
Chrome: 76.0.3809.132
Firefox: 67.0.2
Safari: 12.1.2
npmPacotes:
gatsby: ^ 2.13.73 => 2.15.0
npmGlobalPackages:
gatsby-cli: 2.7.40

Eu estou experimentando o mesmo problema.

Alguma direção que encontrei:

1. O downgrade de gatsby-plugin-sitemap de 2.2.9 para 2.2.6 resolveu o problema com yarn develop .

   • É estranho porque gatsby-plugin-sitemap não deve afetar a construção de desenvolvimento.

2. yarn build ainda não funciona, mas quando removo gatsby-plugin-sitemap minha configuração, yarn build funciona novamente.

@sharvit posso relatar que isso não funcionou no meu caso. Ainda bem que corrigiu para você, eu acho que tem algo a ver com os arquivos de bloqueio e algum problema de versão estranha nas entranhas do arquivo de bloqueio.

Eu consegui voltar a uma compilação de trabalho, na maioria das vezes, talvez 8/10 vezes, revertendo para um arquivo de bloqueio antigo e copiando e colando. Agora também posso CTRL + C para forçar o encerramento da compilação se ela estiver travada, o que não consegui fazer em um ponto deste processo. Não sei o que corrige no arquivo de bloqueio, mas acho que as pistas estão no repositório que postei acima com duas cópias de um arquivo de bloqueio, um que funciona e outro que não. Este é um inseto estranho. Normalmente, em computadores, as coisas funcionam ou não funcionam de forma reconfortante.

@steinitz Teve sorte do seu lado? Eu tive o que você mencionou acontecer. Pareceu ficar melhor, muito bom, mas não perfeito, e agora está falhando quase todas as vezes. Muito frustrante.

@ehowey

Como você pode imaginar, devido à natureza desse problema, estou hesitante em relatar. Aqui está um caso em questão:

Depois de excluir o diretório node_modules, exclua yarn.lock e execute
npx yarn-upgrade-all
e
yarn install
tudo foi bem.

Então, agora mesmo, em resposta à sua mensagem, tentei
yarn start
Resultado: ele trava novamente em
source and transform nodes

Suponho que haja duas coisas sensatas a fazer:

1. siga o conselho de @georgiee para fazer a depuração do Webstorm funcionar com
   node --inspect e ver se consigo identificar algum problema óbvio
2. deixe Gatsby de lado por um tempo para ver se alguma pessoa inteligente resolve o problema

Atualizar:

ctl-C tinha o processo travado acima (que não costumava parar o processo travado, o que era duplamente irritante).
Então yarn start ficou preso em createPagesStatefully .
ctl-C'd novamente, outro yarn start - preso em source and transform nodes
ctl-C'd mais uma vez (pelo inferno com isso) - desta vez yarn start funcionou e está funcionando

Não sei o que fazer com isso, mas aí está.

Isso é semelhante ao que estou vendo, esta noite parece pior, talvez construindo com sucesso 1/10 vezes ou menos. De uma perspectiva de programação / codificação, este é um comportamento muito estranho. Curiosamente, parecia estar funcionando melhor alguns dias atrás em 2.15.1 do que hoje em 2.15.6. Eu também me pergunto quais pontos em comum todos nós compartilhamos que estão causando esse bug. Você pode executar o comando gatsby info --clipboard e publicá-lo?

Obviamente, não é muito difundido, caso contrário haveria uma enxurrada de relatórios, mas também não sou apenas eu como pensei originalmente. Todos parecemos estar usando fios também, o que é um requisito para mim, pois estou trabalhando em temas em uma área de trabalho de fios. Ainda consigo reproduzir isso no gatsby-starter-hello-world, então acredito que seja algum problema de dependência ou conflito nos arquivos principais do gatsby.

@ehowey aqui está o gatsby info você solicitou

Sistema:
OS: macOS 10.14.6
CPU: (4) x64 Intel (R) Core (TM) i7-5557U CPU @ 3,10 GHz
Shell: 3.2.57 - / bin / bash
Binários:
Nó: 12.9.1 - / usr / local / bin / node
Fio: 1.17.3 - / usr / local / bin / yarn
npm: 6.11.2 - / usr / local / bin / npm
Línguas:
Python: 2.7.16 - / usr / local / bin / python
Navegadores:
Chrome: 76.0.3809.132
Firefox: 68.0.1
Safari: 12.1.2
npmPacotes:
gatsby: ^ 2.14.3 => 2.14.7
imagem 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-helmet: ^ 3.1.5 => 3.1.5
gatsby-plugin-robots-txt: ^ 1.5.0 => 1.5.0
gatsby-plugin-sharp: ^ 2.2.18 => 2.2.18
gatsby-plugin-sitemap: ^ 2.2.9 => 2.2.9
imagens-observação-gatsby: ^ 3.1.19 => 3.1.19
gatsby-observação-prismjs: ^ 3.3.9 => 3.3.9
gatsby-source-filesystem: ^ 2.1.18 => 2.1.18
gatsby-transformador-observação: ^ 2.6.19 => 2.6.19
gatsby-transformador-afiado: ^ 2.2.12 => 2.2.12
npmGlobalPackages:
gatsby-cli: 2.7.40

Eu estava tendo o mesmo problema: o site foi construído perfeitamente no Netlify, mas travou na minha máquina de desenvolvimento com gatsby build e gatsby develop .

Depois de brincar com as versões do pacote, percebi que reverter gatsby-plugin-sitemap da versão 2.2.10 para 2.2.9 corrigiu o problema para mim. Curiosamente, algumas pessoas aqui parecem ter problemas com o 2.2.9, o que pode significar que o problema está em outro lugar.

Edit: Falou muito cedo, Gatsby ainda trava nas etapas "source and transform nodes" e "createPagesStatefully", embora com muito menos frequência.

@goblindegook este parece ser um padrão comum com este problema específico. Porque o problema vai e vem, aparentemente com o clima, a hora do dia, o tempo desde a inicialização ... você pode acreditar que algo que você fez o consertou - apenas para que ele se repita.

Também enfrentando esse problema, rebaixou gatsby-plugin-sitemap para 2.2.6 e isso parece ter corrigido o problema

FWIW, também estou passando por isso, mas não use yarn nem gatsby-plugin-sitemap .

Meu gatsby info caso ajude:

  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 mim, limpar o cache com gatsby clean resolveu o problema.

Ainda estou caçando, tentando descobrir isso. Ainda é um problema para mim. Alguém sabe se isso pode estar relacionado com a mudança de babel 7.0.0 -> 7.5.5. Essa mudança aconteceu na época em que comecei a experimentar esse bug e coincide comigo começando a ver problemas ... Tenho tentado fazer as resoluções de fio funcionarem para definir as versões do babel em 7.0.0, mas não tive sucesso com isso ainda.

Acho que posso oferecer algumas dicas - comecei a ter esse problema quando, na metade da adição de plug-ins a um projeto, atualizei gatsby-cli em outra janela de terminal. Executar gatsby clean no meu projeto funcionou.

de https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 - Também estou vendo esse problema, mas gatsby clean não o resolveu. Parece que pode ser que a impressão CLI está travando, e é por isso que redimensionar o terminal corrige isso ?? 🤷‍♂ 😕 ❓❗️

Redimensionar a janela do terminal parece corrigir isso para mim! Eu não testei muito extensivamente. Outras pessoas com esse problema também podem tentar? Que bug estranho e solução potencialmente estranha.

Estou enfrentando exatamente o mesmo problema - gatsby fica preso em "source and transform nodes" ou "createPagesStatefully" frequentemente, e _não_ estou usando plug-ins de origem. Eu só encontrei recentemente a correção "redimensionar janela de terminal" e estou 140% perplexo sobre como diabos isso corrige, mas ele corrige. Este parece ser um problema muito sério!

@JaKXz - Obrigado! Isso estava me deixando louco. A correção parece ser o redimensionamento da janela do terminal no VS Code. Basta arrastá-lo para cima ou para baixo um pouco e a tarefa de desenvolvimento funcionará alegremente. Eu testei em alguns casos diferentes, yarn e npm, em espaços de trabalho ou não. Parecia estar funcionando em todos esses casos para mim. Ele também parece travar ou travar em createPagesStatefully mais frequência do que source and transform nodes agora para mim. Vou deixar o assunto em aberto por enquanto, pode ser necessário consertar de uma forma menos "hacky" por alguém com mais know how do que eu.

@ehowey Eu tenho o mesmo problema e mover a janela do terminal no vscode funciona (não podia acreditar quando li esse problema até tentar por conta própria).
Você sabe se isso só acontece no VS Code?

Eu tenho esse problema no iTerm 2, então não é específico do VS Code.

Meu problema também foi no iTerm 2

Terminal Webstorm, Terminal Mac, iTerm

A correção do terminal de redimensionamento funcionou para todos vocês em diferentes ambientes de desenvolvimento?

Do meu lado, o redimensionamento do terminal funcionou no iTerm e VSCode (dei algumas tentativas para reproduzir o problema no iTerm)

O truque do terminal de redimensionamento funciona de forma confiável para mim no iTerm 2.

Sim, redimensionar o iTerm 2 funciona perfeitamente

Se o redimensionamento funcionar, suspeito que esse bug esteja relacionado ao buffer, em algum lugar precisa de liberação de stdout.

Este parece ser um problema relacionado ao kernel + shell. Provavelmente de alguma forma que o nó interage com seu kernel e / ou shell. Só digo isso porque não consigo replicar os problemas usando Linux ou Windows. Não consigo encontrar nenhum problema conhecido, então a) é alguma combinação de padrões de código exclusivos de Gatsby + a interação com o sistema, ou b) Eu simplesmente não sei a pergunta certa a fazer ainda.

Se o redimensionamento do terminal corrigir o problema, pode haver alguma falha entre o nó e kqueue causando um bloqueio no loop de eventos. O redimensionamento do terminal envia ao processo um sinal SIGWINCH, que interrompe o loop de eventos, o que o libera e permite que continue.

Você pode tentar executar kill -SIGWINCH ${pid} no processo em execução quando ele congela? Deve agir da mesma forma que redimensionar o terminal.

Também estou interessado em saber se isso acontece ou não em todos os shells. Com base nas informações até agora, isso tem falhado em bash e zsh , e este é provavelmente um dos fatores comuns entre todos os emuladores de terminal. Vocês podem tentar um ou mais dos sh , csh , ksh , tcsh , etc ...?

Se o problema ocorrer em todos os shells, então acho que é a maneira como o kernel está lidando com o loop de eventos do nó. Também pode ser por isso que é um problema intermitente. Se alguma função obtém menos tempo de processador (talvez por causa da carga variável do sistema), ela pode bloquear por muito tempo e talvez o kernel tente reutilizar um nó de evento em algum lugar, resultando em um deadlock? Não estou muito familiarizado com os componentes internos da API, mas aposto que source and transform nodes consome bastante IO do sistema de arquivos. Isso significa que provavelmente há muito descarregamento acontecendo, então quem sabe o que realmente está acontecendo nos níveis mais baixos.

Acho que seria uma boa ideia tentar diminuir a área de superfície desse bug. Parece que ocorre com mais frequência em source and transform nodes , então talvez tente restringir para qual plug-in está bloqueando. Tente adicionar as seguintes linhas 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       })));

Em seguida, execute node inspect node_modules/.bin/gatsby develop . Ele irá quebrar assim que começar, então você deve pressionar c quando chegar ao prompt debug> e esperar que continue. Quando quebrar nessa linha debugger , escreva exec console.log(plugin) e observe o que diz em resolve . Em seguida, pressione c para continuar. Faça isso até travar ... se travar.

Devido à natureza do loop de eventos, aposto que ele nem mesmo travará durante a depuração. Essas interrupções são provavelmente suficientes para mantê-lo sob controle. Os bugs assíncronos podem ser muito difíceis de rastrear. Se ele não travar durante o uso do depurador, substitua a linha debugger por:

reporter.log(plugin.resolve);

Esperançosamente, isso irá revelar algo. Seria bom ver qual plugin está causando o bloqueio. Se pudermos descobrir isso, talvez possamos descobrir o que precisa ser otimizado / refatorado para resolver isso.

O redimensionamento funciona para mim também, eu uso zsh como meu shell VSCode.

@ Js-Brecht - Obrigado por dedicar seu tempo para uma resposta tão detalhada. Eu não tinha certeza de onde deveria inserir kill -SIGWINCH ${pid} . Não consegui fazer isso durante o processo de construção.

Com o depurador, o código a seguir saiu ... além de mim, para entendê-lo. Na verdade, fiquei preso no depurador, mas .exit ainda funcionou.

⠋ 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, redimensionamento funcionou para mim.

@ehowey Só para saber que estou entendendo corretamente, ele gatsby-source-filesystem é o culpado, o que faz sentido para mim ... especialmente por causa dos problemas existentes relacionados ao Gatsby.

Eu gostaria de ver se o plugin pode lidar com uma execução de teste. Se ele travar durante a execução de testes, acho que será uma maneira fácil de ver onde está falhando. Senão, bem ... só terei que fazer algumas dissecações / depurações, o que será difícil para mim, já que não tenho MacOS.

Você pode baixar o repositório gatsby principal e executar os testes 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'

Além disso, você está fazendo tudo isso com seu repositório de reprodução mínimo? Vejo que gatsby-plugin-mdx foi executado duas vezes, o que me diz que não é um repositório barebones. Em um mundo perfeito, isso não deveria importar, mas acho que seria melhor executar uma configuração o mais simples possível. Se você não conseguir fazer com que ele falhe de maneira confiável com o repo mínimo, use o que falhar mais consistentemente (no mesmo lugar, todas as vezes (ou perto de))

😉

kill -SIGWINCH ${pid} deve ser executado a partir de outra instância do shell. Quando a compilação travar, abra outra janela / guia do terminal e execute o comando a partir dela. Este pequeno snippet deve 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 }')

Se houver erros, tente executar os comandos separadamente:

# 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

Se você ficar de mãos vazias depois de executar os testes, acho que será útil ter um dump de memória, para que possamos obter um rastreamento de pilha. Mas um passo de cada vez.

@ Js-Brecht Desculpe pelas respostas mais lentas ... este é realmente apenas um passatempo secundário que faço nas horas vagas à noite.

Então eu executei a mesma coisa dentro do gatsby hello world starter - o mais básico possível. Desculpe por executá-lo antes em meu espaço de trabalho principal em um projeto que estava tendo problemas. Eu já o repliquei anteriormente no starters, então eu não acho que ele se relaciona a um plugin, mas sim a algo no núcleo do gatsby.

Ele fica suspenso nos nós de origem e de transformação, fornecendo a seguinte saída:

< 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

Aqui está um dump do comando gatsby info, caso seja ú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 uma observação lateral - quando eu uso seu comando debug, ele trava nos nós de origem e transformação. Quando eu uso o gatsby Develop, ele fica suspenso em createPagesStatefully agora para mim. Desculpe, eu sei que este é realmente estranho. Para ser honesto, não tenho certeza de quanto trabalho vale a pena você terminar. O truque de redimensionar a janela do terminal funciona sempre para mim e para os outros. É uma solução hacky, mas não deve afetar tantos usuários, caso contrário, os problemas seriam inundados.

Isso começou a acontecer aqui também. O truque _resize the terminal_ resolve isso; muito estranho!

+1 Não funciona no iTerm2, mas funciona no Terminal 🤷‍♂️

@ehowey A maioria do que está acontecendo durante a construção é definido por um plugin ou outro. Gatsby vem com eles como dependências; Suponho que eles possam ser considerados plug-ins principais. O núcleo de Gatsby expõe uma API, que procura pontos de extremidade definidos nos plug-ins e os passa uma série de argumentos que incluem ações / objetos definidos no núcleo. Então, sim, o que está acontecendo pode estar acontecendo no núcleo, mas primeiro é necessário chamar um plug-in, e esses plug-ins definem um contexto específico para a API. Estou tentando determinar o contexto que está resultando na interrupção da compilação e também preciso verificar se o problema não está ocorrendo no próprio plug-in.

Posso pedir para você mudar essas linhas?

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

Execute-o e copie / cole todo o resultado (pode até anexá-lo à sua resposta como um arquivo .txt ). Será consideravelmente mais prolixo e muitas informações provavelmente serão desnecessárias, mas 🤷‍♂.

Depois de fazer isso, gostaria de ver se aumentar o pool de threads do nó faz alguma diferença. Observei outros problemas que mencionam o mesmo ou problemas semelhantes. Principalmente eles ocorrem em source and transform , e alguns falam sobre esse estágio durar uma eternidade, ou travar completamente. Então, eu quero ver se acontece algum tipo de impasse no sistema de arquivos io ... o acesso assíncrono do sistema de arquivos é descarregado pelo nó para diferentes threads e, por padrão, o nó tem apenas um pool de 4 threads para o espaço do usuário. Se esses se encherem e for necessário fazer mais algum descarregamento, as tarefas serão enfileiradas no loop de evento principal, esperando por um thread. Isso poderia, potencialmente, paralisar todo o programa ... até que um tópico se tornasse disponível. Gatsby mantém um cache no sistema de arquivos, então talvez haja uma colisão ocorrendo em algum lugar, e se houver algum tipo de impasse acontecendo, então talvez os threads estejam esperando por um tempo limite / interrupção antes de prosseguir, e se houver dezenas (ou centenas, até) de eventos de acesso ao sistema de arquivos, todos eles podem estar esperando pelo mesmo tempo limite e fazendo com que tudo se acumule. Você pode ver que isso pode fazer com que o tempo de espera cresça rapidamente.

Aumentar o tamanho do pool pode ajudar a aliviar parte do tráfego ... ou pode acontecer da mesma maneira, apenas com mais threads 😆.
Tente o seguinte comando:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht Alterar o tamanho do pool de threads não pareceu fazer muita diferença.
Eu obtenho a seguinte saída do comando gatsby develop padrão com as alterações que você mencionou acima. Ainda no básico starter 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 é um exemplo onde ele fica em createPagesStatefully . Consegui continuar a construção redimensionando a janela do terminal. Qual é internal-data-bridge qualquer chance de que possa ser o culpado de alguma forma? Isso estava presente em ambos os comandos que você me pediu para executar até agora.

Você pode mostrar em que linha ele pendurou?

createPagesStatefully dev-404-page

Não estou 100% certo se a parte dev-404-page estava lá, mas parou na primeira instância de createPagesStatefully

Obrigado. Eu gostaria de tentar mais algumas mudanças agora, se você não se importa.

Por favor, atualize as linhas indicadas nos seguintes arquivos:

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

Suspeito que chokidar pode ser o culpado aqui. Ele foi atualizado para v3.x cerca de um mês atrás e parece que eles começaram a usar fsevents ou fizeram algo que causou algum comportamento errôneo em relação a fsevents . Eles têm alguns problemas em aberto semelhantes aos que estamos enfrentando aqui, com nó suspenso ao usar chokidar.watch() . Isso parece caber, uma vez que está localizado para MacOS devido a fsevents ser um processo Mac, e a compilação parece estar falhando nos módulos onde está sendo usada ou em módulos que estão escrevendo / processando arquivos que provavelmente estão sendo assistidos.

chokidar.watch() existe em gatsby-source-filesystem , também, e é aí que ele estava falhando com seu outro repo, @ehowey; sem mencionar que gatsby-source-filesystem não está sendo chamado em seu repo mínimo, o que meio que explica por que ele está passando de source and transform . Existem instâncias de chokidar antes de internal-data-bridge , mas acho que em locais que não estão afetando a construção (por exemplo, query-watcher ). No entanto, acredito que internal-data-bridge é o motivo pelo qual ele estava travando durante a execução do depurador; e em uma execução direta, provavelmente estava afetando os estágios posteriores da construção.

Informe se isso corrige os problemas ou mesmo se torna o problema ainda mais difícil. :dedos cruzados:

@ Js-Brecht Você está chegando a algum lugar! Corri gatsby develop provavelmente 15 vezes. Nunca pendurou em source and transform nodes ou createPagesStatefully mas parecia pendurar, talvez 2/10 vezes, em start webpack server . Eu poderia adicionar isso junto com o truque do terminal de redimensionamento também. Alguma chance de você ter perdido uma instância de chokidar / fsevents que estaria relacionada a start webpack server ?

Como uma observação lateral, ele também pareceu passar pelas etapas do processo de desenvolvimento muito mais rápido do que antes, se isso tem algo a ver com isso?

É muito bom ouvir isso. Eu deixei uma instância do chokidar, propositalmente, e é logo depois que ele termina o bootstrap e inicia o servidor. Ele está em node_modules/gatsby/dist/commands/develop.js próximo ao final da função startServer() . Não estou em um computador agora, ou daria uma diferença.

Você pode encontrar a linha exata fazendo:

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

Eu tinha certeza de que se isso corrigisse o bootstrap, ele ainda teria que travar no servidor. Avise-me se alterar isso torna o funcionamento confiável, e enviarei um PR e cuidarei para que as pessoas saibam.

Na verdade, não estou surpreso que isso o torne mais rápido. A construção de um projeto básico geralmente leva cerca de um segundo, e eu vi alguns tempos de execução longos e loucos para certos estágios em sua saída de depuração. fsevents supostamente acelera as coisas e tira grande parte da carga da CPU, mas há algo engraçado acontecendo que está fazendo isso travar.

@ Js-Brecht Meu chapéu vai para você. Não tenho ideia de como você tirou aquele coelho da cartola e o bug consertou um coelho estranho à distância, mas bom trabalho! Vou esperar que o diff faça alterações em develop.js pois não quero alterar nada errado, mas suspeito que isso vai consertar, pois estava pendurado na última etapa quando inicia o servidor alguns de vezes.

Aqui está a diferença:

node_modules/gatsby/dist/commands/develop.js

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

Agradeço muito sua ajuda, executando todos esses testes. Essa tem sido complicada, mas tem sido uma oportunidade para mergulhar no interior do MacOS, e eu sempre gosto de aprender coisas novas: ligeiramente_smiling_face:

Por favor, deixe-me saber como foi; ainda não completamente fora de perigo: sweat_ smile :.

Trabalho! Acabei de executar gatsby develop 10+ vezes e funcionou perfeitamente. Obrigado por sua ajuda em investigar isso. Esperançosamente, isso contribui para uma melhoria para o grupo de nós que está passando por isso!

Ótimo! Daqui a pouco, quando tiver alguns minutos, farei uma RP. Depois de feito isso, você poderá usar gatsby-dev-cli com meu repo para ter um ambiente de desenvolvimento funcional até que um patch seja publicado (se você não estiver familiarizado com gatsby-dev-cli , eu posso Socorro). Posso tentar recrutá-lo para testar as alterações de qualquer maneira, já que não tenho o sistema operacional correto ... o mesmo vale para todos os outros neste tópico que estão enfrentando esse problema.

Vou postar de volta aqui quando estiver pronto.

Encontrei outro problema separado que também causa esse sintoma - https://github.com/gatsbyjs/gatsby/issues/17935

Se alguém estiver usando LokiJS e redimensionar o terminal não resolver o problema, é bem provável que seja o problema que encontrei.

Ei pessoal, @ehowey , por favor,

Você pode pegar meu repositório e usá-lo como sua fonte gatsby em seu site usando gatsby-dev-cli . Primeiro, você precisa de gatsby-dev-cli

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

Em seguida, basta clonar o repo e inicializá-lo.

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

Em seguida, vá para o site em que deseja usar o repo e execute gatsby-dev

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

no meu caso, estou usando OSX e IntelliJ, tive que:

• Feche o projeto no IntelliJ
• Tente novamente ( npm start )
• e reabrir o projeto no Intellij
  Acho que o problema está relacionado aos arquivos de indexação do IntelliJ

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

Algum de vocês está disposto a testar o # 17938?

Devo poder dar uma olhada mais tarde esta noite, quando estiver em casa. Obrigado por todo o seu trabalho nisso!
Em 1º de outubro de 2019, 10:23 AM -0600, Jeremy Albright [email protected] , escreveu:

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel
Algum de vocês está disposto a testar o # 17938?
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Alguma atualização sobre a correção para isso? Ele está congelando na origem e nos nós de transformação para mim e para meu amigo depois de tentar [Firebase Source] Fetching data for ...

Redimensionar o terminal, infelizmente, não parece resolver isso para nós

@ rishabhaggarwal2 Existe um problema semelhante que parece ser o que você está enfrentando, em que ficará travado ao recuperar dados de uma fonte online. Você pode tentar usar GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Vendo isso também. Não é possível executar gatsby develop localmente na inicialização do lúmen. Continua pendurado em createPageStatefully ou source and transform nodes

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

Para qualquer outra pessoa que encontre esse problema, tente

CHOKIDAR_USEPOLLING=1 gatsby develop

Isso deve desabilitar fsevents no MacOS, o que parece ser uma solução alternativa confiável.

@ Js-Brecht Eu confirmo que parece corrigir isso de forma mais permanente do que as outras soluções alternativas mencionadas aqui. Obrigado por compartilhar.

@steinitz você diz “mais” permanentemente. Você quer dizer que ainda acontece quando você usa essa opção?

@ Js-Brecht Não, desculpe não estar claro.

Eu estava aludindo ao fato de que outras soluções alternativas, incluindo a minha, pareciam funcionar por um tempo, mas o problema voltou. Com sua solução eu provoquei fazendo mudanças e reexecutando gatsby developers (com sua melhoria), mas a compilação continua funcionando.

Dito isso, esta foi uma viagem de montanha-russa, então continuo emocionalmente preparado: sorria: para que o problema volte.

Para ser claro: até agora, tudo bem.

Ops, atualização: reiniciei o WebStorm para um teste final antes de postar isso e agora ele está pendurado em source and transform nodes no terminal WebStorm.

Para qualquer outra pessoa que encontre esse problema, tente

CHOKIDAR_USEPOLLING=1 gatsby develop

Isso deve desabilitar fsevents no MacOS, o que parece ser uma solução alternativa confiável.

@ Js-Brecht Estou usando o ubutu 18.04 e estou tendo o mesmo problema ocasionalmente. Existe alguma sugestão para o meu SO? Você poderia fornecer alguns detalhes sobre as possíveis causas desse problema?

Isso foi resolvido graças ao trabalho diligente de @ Js-Brecht e @RomanHotsiy. Era um problema de upstream em fsevents, muito além do que eu poderia ter descoberto sozinho, e deve ser corrigido em atualizações futuras, uma vez que essas mudanças sejam implementadas e migrem de fsevents para o próprio gatsby. Por enquanto, uma solução alternativa confiável é redimensionar a janela do terminal. Há uma maneira de corrigir isso em seu repo, que é discutido aqui: https://github.com/gatsbyjs/gatsby/pull/17938, no entanto, você teria que refazer isso corrige após qualquer alteração na pasta node_modules e pode não valer a pena o trabalho, dependendo da frequência com que você atualiza as versões do pacote.

Vou deixar o problema em aberto até que a correção migre para o próprio gatsby.

@ Boty22 Ubuntu não usa fsevents , então provavelmente é algo diferente. Alguns problemas foram encontrados ao recuperar dados de um local remoto; verifique os números 6654 e 17940 para obter alguns detalhes sobre como corrigir problemas de simultaneidade.

Pergunta rápida: redimensionar seu terminal ajuda? Se sim, pode ser _algo_ semelhante a este problema.

@ Js-Brecht redimensionar o terminal não ajuda no Ubuntu. Estou recuperando dados de uma tabela AirTable usando o plugin gatsby-source-airtable BTW

Esse pode ser o problema. Confira este comentário . Se isso não funcionar, pode ser melhor abrir um novo tíquete

@steinitz desculpe, eu perdi seu comentário. Você pode tentar a correção descrita em # 17938? Mais especificamente, aqui e aqui . Se não funcionar, provavelmente há mais coisas acontecendo no seu caso.

Não tive nenhum problema com CHOKIDAR_USEPOLLING=1 gatsby develop desde mencionado.

Obrigado pela solução alternativa @ Js-Brecht

Também estou vendo isso com 2.15.28 quando faço gatsby build. Preciso interromper o desenvolvimento do gatsby no outro terminal? Está acontecendo intermitentemente

Aconteceu novamente sem o servidor de desenvolvimento em execução. Eu tenho um blog simples de seguir o tutorial do blog.

Parece ser quase todas as outras execuções. Estou em um Mac aliás

@canvaspixels redimensiona a janela do terminal obstrui sua construção? Em caso afirmativo, tente fazer isso e nos informe se isso ajudou https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991

@RomanHotsiy isso realmente classifica! Obrigado!

Olá a todos, a versão corrigida de fsevents foi publicada. Você deve ser capaz de simplesmente deletar o arquivo yarn.lock e executar o yarn novamente. Cada uma de suas dependências deve pegar [email protected] automaticamente, o que deve resolver o problema.

Tenha cuidado - deletar todo o seu arquivo yarn.lock também pode fazer com que outros pacotes sejam atualizados.

Outra opção mais precisa se você estiver usando yarn é excluir apenas as linhas relacionadas a fsevents em yarn.lock e executar novamente yarn . Isso fará com que apenas o pacote afetado seja atualizado. Então, por exemplo, removi as seguintes linhas:

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

Outra maneira de fazer isso é usar o recurso resolutions do Yarn (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/). Ao adicionar o seguinte ao seu package.json e, em seguida, executar yarn , ele também atualizará as dependências transitivas e atualizará seu arquivo yarn.lock :

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

Depois de fazer isso e de atualizar seu arquivo de bloqueio, você pode remover a propriedade resolutions de package.json novamente.

Editar: versão anterior e incorreta das instruções removidas.

Você também pode executar yarn upgrade chokidar@latest . Isso deve reconstruir o arquivo de bloqueio com a versão correta de fsevents, sem tocar em mais nada

Oh espere. Isso somente se você tiver chokidar como uma dependência direta 🙄. Esqueci. @karlhorky está certo

Estou usando npm . Excluir node_modules , executar npm i --save [email protected] e npm i resolveu o problema para mim. Demorou 19s para iniciar e estou usando gatsby-lumen-starter como base.

- Editar:

Na verdade, terminei o que estava fazendo, enviei para o Netlify e não foi possível construir por causa de fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ).

Mudei para yarn e tive o mesmo problema, então removi fsevents inteiramente, e agora local e netlify estão funcionando ...

Tive o mesmo problema e não consegui rastrear o motivo. Isso aconteceu comigo no Mac e no PC. Poderia tentar relacionar isso com a velocidade da internet, porém isso aconteceu comigo também quando estava conectado a uma rede de alta velocidade. O que parece estar funcionando para mim agora é adicionar isso ao meu ambiente

GATSBY_CONCURRENT_DOWNLOAD=5

e executando usando --v8-pool-size=128

No meu caso, parece ser o prompt do meu firewall no osx. Se eu for rápido o suficiente para permitir ou negar conexões vindas de fora, o sucesso será perfeito. O problema é que a caixa de diálogo de prompt aparece por uma fração de segundo e desaparece conforme Gatsby continua e, em seguida, falha ao se pendurar em uma das muitas etapas mencionadas acima.
Opções:

• desabilitar firewall (não tendo isso)
• Gatsby na lista de permissões (não é consistente entre projetos e atualizações)
• encontre uma maneira de parar no prompt até que o usuário selecione a opção
• endereço de ligação padrão para localhost (não deve requerer prompt para aceitar conexões de entrada).

@thomasthep O endereço de vinculação padrão para o servidor de desenvolvimento já é localhost. Ele nem escuta conexões externas, a menos que você diga a ele para usar seu endereço IP externo (ou 0.0.0.0). E mesmo assim, ele não inicia o servidor de desenvolvimento até que o bootstrap / build seja concluído. Se for o bootstrap que está causando o prompt do firewall, isso terá mais a ver com os plug-ins que você está usando, porque Gatsby não alcança a Internet em seu estado padrão.

Não deveria haver nenhuma conexão "vinda de fora", em geral; mesmo quando um plugin está coletando informações de uma fonte externa, a conexão se origina de seu host local, não da fonte externa, e que geralmente é aceita como uma "conexão estabelecida" pela maioria dos firewalls, em minha experiência, já que a maioria dos firewalls são configurados para aceitar qualquer conexão de saída.

Eu poderia ver isso acontecendo se o seu firewall estivesse configurado para bloquear processos, em vez de apenas conexões. Nesse caso, seria o Node que precisaria ser incluído na lista de permissões.

Precisaria de mais informações para realmente entender por que isso está acontecendo com você. Porém, provavelmente seria mais eficaz abrir um novo tíquete. Este tinha a ver com fsevents causando problemas no MacOS, e isso foi resolvido, é por isso que está fechado agora. Qualquer coisa não relacionada a fsevents realmente deve ter seu próprio problema, para obter a atenção que merece.

Para o registro, isso também pode acontecer se você tiver seu servidor GraphQL executando no modo de depuração e ele for interrompido em um ponto de interrupção.

Para registro: Isso começou a acontecer comigo quando adicionei gatsby-source-s3-image e o intervalo s3 atingiu mais de 100 imagens. Ele passa por todas as 145 imagens no estágio source and transform nodes e fica lá para sempre. Ainda está acontecendo, tentei as correções acima. Felizmente, ele funciona após 5-6 tentativas, então não estou bloqueado.

O redimensionamento estranho da janela do terminal funcionou para mim

Para mim, limitar downloads simultâneos conforme descrito aqui parece ajudar.

Eu adicionei a seguinte linha ao meu arquivo .env. O padrão é 200.
GATSBY_CONCURRENT_DOWNLOAD=50

Não tenho certeza se isso resolve o seu problema, mas talvez ajude alguém :)

@ rishabhaggarwal2 Existe um problema semelhante que parece ser o que você está enfrentando, em que ficará travado ao recuperar dados de uma fonte online. Você pode tentar usar GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Obrigado, isso consertou para mim. Já que eu estava puxando uma tonelada de conteúdo de um site de terceiros, ele continuou pendurado no download do conteúdo. (97% - tão perto ainda até agora)