@ jonathan-chin você pode fornecer informações ambientais relevantes executando gatsby info --clipboard ?

Além disso, percebi que você está usando Gatsby v1 de seu package.json no repo que compartilhou. Use gatsby-cli versão 1.x.x para Gatsby v1. gatsby-cli version 2.x.x é para Gatsby v2

@kakadiadarpan

  System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 9.4.0 - /usr/local/bin/node
    Yarn: 1.3.2 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Safari: 12.0
  npmPackages:
    gatsby: ^1.9.277 => 1.9.278
    gatsby-image: ^1.0.24 => 1.0.55
    gatsby-link: ^1.6.28 => 1.6.46
    gatsby-plugin-canonical-urls: ^1.0.11 => 1.0.18
    gatsby-plugin-google-analytics: ^1.0.12 => 1.0.31
    gatsby-plugin-google-fonts: 0.0.3 => 0.0.3
    gatsby-plugin-material-ui: ^0.1.3 => 0.1.3
    gatsby-plugin-nprogress: ^1.0.10 => 1.0.14
    gatsby-plugin-react-helmet: ^1.0.5 => 1.0.8
    gatsby-plugin-react-next: ^1.0.11 => 1.0.11
    gatsby-plugin-sass: ^1.0.26 => 1.0.26
    gatsby-plugin-sharp: ^1.6.48 => 1.6.48
    gatsby-remark-autolink-headers: ^1.4.8 => 1.4.19
    gatsby-remark-copy-linked-files: ^1.5.36 => 1.5.37
    gatsby-remark-external-links: ^0.0.4 => 0.0.4
    gatsby-remark-images: ^1.5.67 => 1.5.67
    gatsby-remark-responsive-iframe: ^1.4.19 => 1.4.20
    gatsby-source-filesystem: ^1.5.8 => 1.5.39
    gatsby-transformer-remark: ^1.7.21 => 1.7.44
    gatsby-transformer-sharp: ^1.6.14 => 1.6.27
  npmGlobalPackages:
    gatsby-cli: 2.0.0-rc.1
    gatsby: 1.9.278

quando faço o downgrade do meu gatsby-cli global para 1.9.X, recebo o problema do CSS. quando eu mantenho em 2.0.0-rc.1, ele me dá o erro BrowserslistError: Unknown browser query dead

@ jonathan-chin Eu entendo que você está tendo o problema de CSS com a versão gatsby-cli 1.9.x , mas essa é a versão que você deve usar, pois é compatível com a versão de Gatsby que você está usando.

Obrigado por compartilhar o repositório de reprodução. Vou dar uma olhada nisso.

@ jonathan-chin seria possível para você dizer qual CSS é exatamente diferente no desenvolvimento vs construção?

@kakadiadarpan
Isso é do desenvolvimento e é o estilo esperado

isso é o que eu obtenho com a construção:

Você pode ver que suas classes CSS são diferentes.

Não me lembro disso ser um problema antes. A última boa compilação (em que o CSS não foi afetado) foi https://gitlab.com/sharemeals/gatsby-site/commit/4342a715d6a1cdcb2808e5450819753be6f56a19

Acho que a solução para isso é # 8092.

@ jonathan-chin você seria capaz de puxar o conteúdo dessa correção e tentar fazer essas alterações? Observação: se você ainda não viu, a seção Como contribuir dos documentos de Gatsby contém informações sobre como configurar o gatsby-dev-cli, que você precisará testar!

Além disso, @ jonathan-chin parece que você está no Gatsby v1. Você seria capaz de atualizar para o Gatsby v2 para obter essa correção?

@DSchau, desculpe por ter demorado tanto para voltar a isso.

migrar o projeto existente para a v2 dava muito trabalho. Decidi começar um novo starter v2 e migrá-lo peça por peça (copiando e modificando conforme necessário). Nesse caso, gatsby development produz uma saída

gatsby build

gatsby desenvolver

comparar os estilos de CSS de dois elementos idênticos na construção e no desenvolvimento:

Construir:

.jss94 {
  color: #fff;
  font-size: 0.875rem;
  font-weight: 500;
  font-family: "Roboto", "Helvetica", "Arial", sans-serif;
  text-transform: uppercase;
}

desenvolve:

.MuiTypography-headline-88 {
  color: #fff;
  font-size: 1.5rem;
  font-weight: 400;
  font-family: "Roboto", "Helvetica", "Arial", sans-serif;
  line-height: 1.35417em;
}

Eu tenho algum material de UI substituindo scss que carrego no componente de layout na v2. no desenvolvimento, parece mesclá-los bem, mas na construção, parece ignorá-los? pode ser essa a causa?

Acabei de ter um import '../scss/style.scss';

@ jonathan-chin você tentou fazer isso com a v2 ou de acordo com as etapas mencionadas no comentário de @DSchau acima?

@kakadiadarpan Desculpe, não tenho capacidade (ou seja, tempo) para configurar esse fluxo de trabalho.

Depois de analisar a correção de RP, parece ser o mesmo problema que estou tendo. Posso encerrar essa edição agora e acompanhar o PR.

@kakadiadarpan desculpe, acabei de perceber algo estranho.

Quando meu site carrega pela primeira vez, o CSS é maluco. mas forçando-o a recarregar a página de índice, o CSS carrega bem. Aqui estão as etapas para reproduzir:

1) carregue https://sharemeals.org/
examine a citação de Emerson na parte inferior:

2) clique no nome do site superior esquerdo. ele irá recarregar a página de índice sem atualizar o site. a citação de emerson aparece conforme o esperado:

(a citação de emerson é um indicativo de outras alterações de CSS. Só estou mencionando este porque é o mais visível)

@ jonathan-chin Obrigado pela atualização. Consigo reproduzir o problema com as etapas fornecidas. Você está usando Gatsby v1 ou v2 para https://sharemeals.org/?

~ Estou tendo exatamente o mesmo problema: ~

~ Ao usar injectGlobal estou obtendo estilos diferentes após executar gatsby build . Você pode ver o problema aqui: https://ivorpad.com/about~

~ Depois que a página terminar de carregar, passe o mouse sobre os links 'Escrita' ou 'Trabalho' e você verá a mudança de estilos. ~

Resolvido movendo os estilos de título para page.js vez de global.

 System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 8.11.4 - ~/n/bin/node
    Yarn: 1.2.1 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/n/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Firefox: 62.0.2
    Safari: 11.1.1
  npmPackages:
    gatsby: ^2.0.7 => 2.0.8
    gatsby-plugin-google-analytics: ^2.0.0-rc.2 => 2.0.0-rc.2
    gatsby-plugin-google-fonts: ^0.0.4 => 0.0.4
    gatsby-plugin-react-helmet: ^3.0.0-rc.1 => 3.0.0
    gatsby-plugin-styled-components: ^3.0.0 => 3.0.0
    gatsby-plugin-typography: ^2.2.0 => 2.2.0
    gatsby-remark-prismjs: ^3.0.1 => 3.0.1
    gatsby-source-contentful: ^2.0.1-beta.15 => 2.0.1
    gatsby-transformer-remark: ^1.7.44 => 1.7.44

@kakadiadarpan que está usando "gatsby": "^1.9.277"

Acho que a solução para isso é # 8092.

@ jonathan-chin você seria capaz de puxar o conteúdo dessa correção e tentar fazer essas alterações? Observação: se você ainda não viu, a seção Como contribuir dos documentos de Gatsby contém informações sobre como configurar o gatsby-dev-cli, que você precisará testar!

@ jonathan-chin você pode tentar as sugestões fornecidas por @DSchau neste comentário?

@kakadiadarpan Acho que tentei implementar isso agora. Eu instalei gatsby-cli-dev, bifurcou e puxou, troquei o branch, etc etc.

O problema ainda persiste.

Como posso verificar se o novo node_modules / gatsby que tenho está correto e não o antigo?

Fiz mais algumas investigações, com Gatsby 1.XX e sem a correção proposta.

(Eu tentei atualizar para Gatsby 2.XX e separadamente a correção proposta e nenhuma funcionou)

a classe jss para o estilo desejado existe no carregamento de página inicial. neste caso, .jss58. No entanto, o elemento que estou olhando não obtém .jss58 no carregamento inicial. somente depois de fazer outra solicitação de página (mesmo solicitando a mesma página) o elemento obterá corretamente .jss58

Então, quem é o responsável por determinar quais classes jss aplicar? há um motivo pelo qual teria um resultado no carregamento inicial, mas um carregamento diferente em todas as solicitações de página subsequentes?

EDIT: existem alguns outros problemas importantes. na versão de produção, meus ícones svg nunca carregam totalmente, independentemente da solicitação da página:

Isso é o que eu obtenho em vez de desenvolver:

Eu estou enfrentando o mesmo problema. As versões gatsby Develop e Gatsby Build são muito diferentes para mim.

Se eu acessar diretamente ou atualizar uma página com componentes material-ui, o CSS será quebrado para esses componentes. As classes estão presentes na fonte, mas não são aplicadas aos elementos. Se eu seguir <Link> para a mesma página, entretanto, tudo funcionará bem.

Também notei que se eu executar gatsby build enquanto gatsby develop estiver em execução, a versão de desenvolvimento do gatsby também começa a se comportar exatamente da mesma maneira que a versão de desenvolvimento do gatsby.

System:
    OS: Linux 3.10 Red Hat Enterprise Linux Workstation 7.3 (Maipo)
    CPU: x64 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
    Shell: 4.2.46 - /bin/bash
  Binaries:
    Node: 11.1.0 - /usr/bin/node
    Yarn: 1.12.1 - /usr/bin/yarn
    npm: 6.4.1 - /usr/bin/npm
  Browsers:
    Chrome: 70.0.3538.77
  npmPackages:
    gatsby: 2.0.37 => 2.0.37
    gatsby-cli: 2.4.4 => 2.4.4
    gatsby-plugin-typography: 2.2.1 => 2.2.1
    gatsby-source-atom: 0.1.0 => 0.1.0
    gatsby-source-ghost: 2.1.2 => 2.1.2
  npmGlobalPackages:
    gatsby-cli: 2.4.4

(Eu nunca usei gatsby-plugin-offline)

Você pode verificar o site em http://pawanhegde.netlify.com
A fonte está em https://gitlab.com/PawanH/pawanh.gitlab.io/tree/gatsbyjs

Para ver a versão "esperada", clique em qualquer um dos ícones comicamente grandes próximos à parte inferior.

Ainda não tive tempo de tentar consertar o # 8092

Ainda não tive tempo de tentar consertar o # 8092

Isso não corrigiu o problema para mim. Ainda vejo o mesmo comportamento.

Esperado

Real

Se eu chegar diretamente ou atualizar uma página ... o CSS está quebrado para esses componentes. As classes estão presentes na fonte, mas não são aplicadas aos elementos. Se eu seguir <Link> para a mesma página, entretanto, tudo funcionará bem.

Isso também está acontecendo exatamente como descrito para mim. Tentei corrigir em https://github.com/gatsbyjs/gatsby/pull/8092 e funcionou para a maioria das páginas, mas não funcionou para todas.

Esperado:

Real:

  System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.10.0 - /usr/local/bin/node
    Yarn: 1.9.4 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 70.0.3538.102
    Firefox: 62.0.3
    Safari: 11.1.1
  npmPackages:
    gatsby: ^2.0.46 => 2.0.46 
    gatsby-image: ^2.0.20 => 2.0.20 
    gatsby-link: ^2.0.6 => 2.0.6 
    gatsby-plugin-catch-links: ^2.0.8 => 2.0.8 
    gatsby-plugin-flow: 1.0.2 => 1.0.2 
    gatsby-plugin-google-analytics: ^2.0.7 => 2.0.7 
    gatsby-plugin-manifest: ^2.0.9 => 2.0.9 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.1 
    gatsby-plugin-root-import: 2.0.4 => 2.0.4 
    gatsby-plugin-sass: ^2.0.4 => 2.0.4 
    gatsby-plugin-sharp: 2.0.12 => 2.0.12 
    gatsby-plugin-sitemap: ^2.0.2 => 2.0.2 
    gatsby-plugin-svgr: 2.0.0-alpha => 2.0.0-alpha 
    gatsby-remark-copy-linked-files: 2.0.6 => 2.0.6 
    gatsby-remark-images: 2.0.6 => 2.0.6 
    gatsby-remark-responsive-iframe: ^2.0.6 => 2.0.6 
    gatsby-remark-smartypants: 2.0.6 => 2.0.6 
    gatsby-source-filesystem: 2.0.8 => 2.0.8 
    gatsby-source-wordpress: 3.0.13 => 3.0.13 
    gatsby-transformer-remark: 2.1.12 => 2.1.12 
    gatsby-transformer-sharp: ^2.1.8 => 2.1.8 

Resolvi esse problema fazendo o seguinte
no arquivo index.js que eu tinha

import 'injectSheet' from react-jss
import './../bootstrap.min.css'

invertendo a ordem, consegui especificar a ordem em que queria importar css no html.
Então, meu código final foi

import './../bootstrap.min.css'
import 'injectSheet' from react-jss

Solução : Alterar ordem de importação
Isso resolveu o problema para mim. Espero que faça o mesmo com você.

Estou tendo os mesmos problemas, entre muitos outros:

• develop é executado de forma não determinística; no entanto, quando é executado, funciona bem.
• StaticQuery não consegue terminar de carregar as imagens de forma não determinística.
• build falha não deterministicamente, geralmente falha de seg em coisas de imagem.
• build saída de develop - este é o fator decisivo.
• develop e build parecem interagir um com o outro.

Esses problemas são tão chatos que, infelizmente, parecem superar qualquer benefício de Gatsby para mim, e me forçam a voltar para Criar aplicativo React.

Tentei várias soluções alternativas, como remover todos os estilos embutidos e importar .scss nos componentes filhos, em vez de no nível raiz.
Ainda assim, o problema persiste. Isso é realmente preocupante

Estou usando componentes estilizados, adicionando gatsby-plugin-styled-components em gatsby-config.js funcionou para mim.

Tendo o mesmo problema.
A construção de Gatsby aplica um nome de classe diferente, mas posso ver no inspetor React a classe adequada sendo aplicada.

System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.14.2 - ~/.nvm/versions/node/v10.14.2/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.14.2/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 59.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.107 => 2.0.107
    gatsby-image: ^2.0.20 => 2.0.25
    gatsby-plugin-google-analytics: ^2.0.9 => 2.0.9
    gatsby-plugin-manifest: ^2.0.9 => 2.0.12
    gatsby-plugin-offline: ^2.0.16 => 2.0.19
    gatsby-plugin-react-helmet: ^3.0.2 => 3.0.4
    gatsby-plugin-react-svg: ^2.0.0-beta1 => 2.0.0-beta1
    gatsby-plugin-sass: ^2.0.7 => 2.0.7
    gatsby-plugin-sharp: ^2.0.16 => 2.0.16
    gatsby-remark-copy-linked-files: ^2.0.8 => 2.0.8
    gatsby-remark-external-links: ^0.0.4 => 0.0.4
    gatsby-remark-images: ^3.0.1 => 3.0.1
    gatsby-source-filesystem: ^2.0.12 => 2.0.12
    gatsby-transformer-remark: ^2.1.15 => 2.1.15
    gatsby-transformer-sharp: ^2.1.9 => 2.1.9
  npmGlobalPackages:
    gatsby-cli: 2.4.6

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Recebemos muitos problemas, então atualmente os fechamos após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.

Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter este problema aberto!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

Por favor, fique aberto.

O problema ainda não foi resolvido. Por favor, fique aberto um pouco

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i5-7287U CPU @ 3.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.10.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.35 => 2.1.4 
    gatsby-cli: ^2.4.10 => 2.4.10 
    gatsby-image: ^2.0.19 => 2.0.29 
    gatsby-plugin-emotion: ^4.0.3 => 4.0.3 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.14 
    gatsby-plugin-manifest: ^2.0.7 => 2.0.17 
    gatsby-plugin-netlify: ^2.0.3 => 2.0.11 
    gatsby-plugin-netlify-cms: ^3.0.12 => 3.0.12 
    gatsby-plugin-offline: ^2.0.10 => 2.0.23 
    gatsby-plugin-purgecss: ^3.1.0 => 3.1.0 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.6 
    gatsby-plugin-sass: ^2.0.7 => 2.0.10 
    gatsby-plugin-sharp: ^2.0.10 => 2.0.20 
    gatsby-plugin-typography: ^2.2.2 => 2.2.7 
    gatsby-remark-copy-linked-files: ^2.0.7 => 2.0.9 
    gatsby-remark-images: ^3.0.1 => 3.0.4 
    gatsby-remark-relative-images: ^0.2.1 => 0.2.1 
    gatsby-source-filesystem: ^2.0.12 => 2.0.20 
    gatsby-transformer-remark: ^2.1.17 => 2.2.5 
    gatsby-transformer-sharp: ^2.1.7 => 2.1.13 
  npmGlobalPackages:
    gatsby-cli: 2.4.5

O problema ainda não foi resolvido. Por favor, fique aberto um pouco

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i5-7287U CPU @ 3.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.10.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.35 => 2.1.4 
    gatsby-cli: ^2.4.10 => 2.4.10 
    gatsby-image: ^2.0.19 => 2.0.29 
    gatsby-plugin-emotion: ^4.0.3 => 4.0.3 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.14 
    gatsby-plugin-manifest: ^2.0.7 => 2.0.17 
    gatsby-plugin-netlify: ^2.0.3 => 2.0.11 
    gatsby-plugin-netlify-cms: ^3.0.12 => 3.0.12 
    gatsby-plugin-offline: ^2.0.10 => 2.0.23 
    gatsby-plugin-purgecss: ^3.1.0 => 3.1.0 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.6 
    gatsby-plugin-sass: ^2.0.7 => 2.0.10 
    gatsby-plugin-sharp: ^2.0.10 => 2.0.20 
    gatsby-plugin-typography: ^2.2.2 => 2.2.7 
    gatsby-remark-copy-linked-files: ^2.0.7 => 2.0.9 
    gatsby-remark-images: ^3.0.1 => 3.0.4 
    gatsby-remark-relative-images: ^0.2.1 => 0.2.1 
    gatsby-source-filesystem: ^2.0.12 => 2.0.20 
    gatsby-transformer-remark: ^2.1.17 => 2.2.5 
    gatsby-transformer-sharp: ^2.1.7 => 2.1.13 
  npmGlobalPackages:
    gatsby-cli: 2.4.5

Conforme referido em https://github.com/gatsbyjs/gatsby/issues/11072, o problema deve ser resolvido em 7058a256d2dcfab91259bdf00e811375737414e7.

Apenas no meu caso de uso específico @emotion/global foi usado para inserir um estilo global no aplicativo. De alguma forma, os problemas de divisão de código ainda persistiam em combinação com as funcionalidades @emotion/global .

Solução alternativa

As etapas a seguir foram executadas para resolver os problemas. Não é uma solução perfeita, mas funcionou nesta configuração.

1. Atualização para a última compilação de Gatsby ^2.1.8
2. Descubra onde import { Global, css } from '@emotion/core' é usado e mova o estilo CSS para um novo arquivo ./styles/global.css
3. Inclua a folha de estilo em sua construção de produção com a adição de gatsby-brower.js à raiz do projeto

// gatsby-brower.js

import './src/styles/globals.css'

1. Limpe o cache antigo e crie a pasta rm -rf .cache && rm -rf public
2. gatsby build -> gatsby serve
3. Voilá 💁‍♂️

Notas

• Eu suspeito que muitos dos problemas acima são causados ​​por maneiras incomuns de inserir estilos (globais) problemas de divisão de código VS CSS mencionados em https://github.com/gatsbyjs/gatsby/issues/11072
• Provavelmente, a solução alternativa acima é uma correção de caso de uso específico.
• Este tutorial sobre estilo em Gatsby me ajudou a resolver isso

Esta é uma questão frustrante.

Para mim, as animações feitas com react-pose nomeadamente em gatsby-browser.js e gatsby-ssr.js estavam fazendo algumas coisas estranhas de vodu, renderização dupla e algumas coisas css indeterminísticas onde a página funcionaria em uma segunda atualização.

Eu ainda não consigo apontar para o problema exato, mas inspecionar e eventualmente remover plug-ins, remover bibliotecas, _solvi_ o.

Embora o Gatsby, junto com outras ferramentas JS, possa ser incrível e chamativo, seja cuidadoso e responsável ao (não) usá-lo na produção.

é possível compartilhar uma nova reprodução? Porque ao usar css-in-js pode ser algo que não podemos consertar, pois não é nossa culpa.

Eu também encontrei esse problema.

Adicionei typography.js alguns dias atrás. Então percebi que os estilos baseados em typography.js funcionam bem em gatsby develop , mas não estão disponíveis em gatsby build . Eu criei os aplicativos a partir do modelo inicial,

Tentei atualizar a versão, não funciona.
Então, descobri que há um layout.css

Minha solução é comentar layout.css e parece resolver esse problema

Projeto após adicionar typography.js
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/ffb52973c21014b247a808e444319f8eede6eee6

Projeto depois de comentar layout.css
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/658c7f8976d8d84a1fd28cb9aa6c99bbce2be9b3

@Jasonlhy Esse era exatamente o problema para mim. O arquivo layout.js na minha pasta de componentes está importando o arquivo layout.css. Depois de remover essa importação e executar npm run build e npm run serve novamente, o site apareceu muito bem. Muito obrigado!

é possível compartilhar uma nova reprodução? Porque ao usar css-in-js pode ser algo que não podemos consertar, pois não é nossa culpa.

Olá @wardpeet , isso apareceu em um projeto meu quando adicionei gatsby-plugin-styled-components, então aqui está uma nova reprodução do problema que continua acontecendo no Gatsby atualizado:

EDIT: Acontece que não tenho mais uma reprodução, porque o problema continua mudando conforme eu edito meus estilos. Depois de implantar meu próximo commit, a ordem das importações mudou novamente. Meu CSS agora é o mesmo em dev e prod. As capturas de tela em anexo e a descrição mostram o que costumava acontecer ...

Descrição

Gatsby pede <head> diferente no desenvolvimento e na produção. Ao usar gatsby-plugin-style-components junto com CSS global, isso pode fazer com que a ordem de carregamento do CSS seja diferente entre dev e prod, levando a erros visuais inesperados.

Isso é idêntico a # 9908, que foi fechado junto com uma série de problemas semelhantes em favor de # 9733, que por sua vez foi fechado porque por @KyleAMathews foi corrigido em # 11800. No entanto, ainda vejo o comportamento de # 9908 depois de garantir que Gatsby seja atualizado.

Passos para reproduzir

Eu tenho um exemplo ativo (mas não mínimo) do problema neste repo: https://github.com/vivshaw/vivshaw. Este site tem um pedaço de CSS global, incluindo o framework Bulma CSS, então o resto do site é feito em componentes estilizados. A versão de produção está ao vivo no netlify .

Resultado esperado

Tanto gatsby develop quanto gatsby build gatsby serve devem ter a mesma aparência. A ordem de carregamento do estilo deve ser consistente.

Resultado atual

Quando construído para produção, vemos o estilo de página correto:

Mas quando o carregamos com gatsby develop , o preenchimento na seção de introdução desapareceu:

Eu fiz algumas pesquisas e descobri o porquê. Na produção, Gatsby carrega o fragmento css global antes dos estilos de componentes estilizados, conforme visível com as duas linhas destacadas aqui:

Mas no desenvolvimento, os estilos de componentes estilizados carregam primeiro:

Por que isso causa um bug? Bem, eu tenho o componente marcado com uma classe Bulma e uma classe gerada com componentes estilizados. Ambas as classes afetam as propriedades de preenchimento, portanto, a que for carregada por último é a que será aplicada. Nesse caso, é facilmente resolvido simplesmente removendo a classe Bulma. Mas posso imaginar situações em que esse comportamento de ordem de carregamento causa o surgimento de problemas mais complexos.

Meio Ambiente

> gatsby info

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
  Binaries:
    Yarn: yarn install v0.27.5
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 118.04s. - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.4.0 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.13 - /c/Python27/python
  Browsers:
    Edge: 42.17134.1.0
  npmPackages:
    gatsby: ^2.3.16 => 2.3.16
    gatsby-image: ^2.0.37 => 2.0.37
    gatsby-plugin-eslint: ^2.0.4 => 2.0.4
    gatsby-plugin-layout: ^1.0.14 => 1.0.14
    gatsby-plugin-manifest: ^2.0.28 => 2.0.28
    gatsby-plugin-netlify: ^2.0.13 => 2.0.13
    gatsby-plugin-netlify-cms: ^3.0.17 => 3.0.17
    gatsby-plugin-offline: ^2.0.25 => 2.0.25
    gatsby-plugin-purgecss: ^3.1.1 => 3.1.1
    gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
    gatsby-plugin-robots-txt: ^1.4.0 => 1.4.0
    gatsby-plugin-sass: ^2.0.11 => 2.0.11
    gatsby-plugin-sharp: ^2.0.32 => 2.0.32
    gatsby-plugin-sitemap: ^2.0.12 => 2.0.12
    gatsby-plugin-styled-components: ^3.0.7 => 3.0.7
    gatsby-plugin-webpack-size: 0.0.3 => 0.0.3
    gatsby-source-filesystem: ^2.0.29 => 2.0.29
    gatsby-transformer-remark: ^2.3.8 => 2.3.8
    gatsby-transformer-sharp: ^2.1.17 => 2.1.17

Obrigado, definitivamente, sem saber como podemos consertar isso, podemos querer adicionar algum tipo de classificação aos componentes do cabeçote.

Vendo o mesmo tipo de problema mencionado acima por @topherauyeung

Meio Ambiente

gatsby info

  System:
    OS: macOS High Sierra 10.13.4
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.7.0 - /usr/local/bin/node
    Yarn: 1.15.2 - ~/.yarn/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 73.0.3683.103
    Firefox: 66.0.2
    Safari: 11.1
  npmPackages:
    gatsby: ^2.3.24 => 2.3.27
    gatsby-image: ^2.0.39 => 2.0.40
    gatsby-plugin-manifest: ^2.0.29 => 2.0.29
    gatsby-plugin-material-ui: ^1.2.4 => 1.2.4
    gatsby-plugin-offline: ^2.0.25 => 2.0.25
    gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
    gatsby-plugin-sharp: ^2.0.35 => 2.0.35
    gatsby-plugin-typography: ^2.2.13 => 2.2.13
    gatsby-source-filesystem: ^2.0.29 => 2.0.31
    gatsby-transformer-sharp: ^2.1.18 => 2.1.18
  npmGlobalPackages:
    gatsby-cli: 2.5.4

Tendo esse problema também. Temos um repositório gatsby que extrai componentes de uma biblioteca NPM. Os componentes importam .scss arquivos que estão sendo injetados em <head> na ordem errada na construção. No desenvolvimento, os estilos do repo gatsby vêm por último, então eles têm precedência, mas na construção eles vêm primeiro e estão sendo substituídos pelos estilos do componente importado.

Tenho um problema semelhante, talvez relacionado a isso, carrego os estilos dinamicamente, no gatsby desenvolvo os estilos são relativos ao layout atual, no gatsby build todos os estilos dentro de 'source.less' são aplicados ao layout do aplicativo também

componentDidMount() { require("./source.less") }

Também encontrei este problema. Mas meu caso foi um erro simples.
Eu estava usando

<Button href="/path/to/page">blah blah</Button>

Quando mudei para usar o Gatsby Link, funcionou

<Link to="/path/to/page">
  <Button>blah blah</Button>
</Link>

Mesmo problema. Fico de olho em uma solução enquanto tento depurar.

Somando a isso porque acho que está relacionado, mas só recentemente:
Estou usando Typography.js, bem como Bootstrap - na produção, o bootstrap é anulado por typography.js, que é o que eu quero, mas no servidor de desenvolvimento os estilos de fonte Bootstrap estão substituindo meus estilos de tipografia. Isso é muito irritante porque preciso implantar o site para ver como ele realmente se parece. Se alguém souber como eu poderia ignorar o Bootstrap com typography.js no gatsby development, eu realmente apreciaria

Somando a isso porque acho que está relacionado, mas só recentemente:
Estou usando Typography.js, bem como Bootstrap - na produção, o bootstrap é anulado por typography.js, que é o que eu quero, mas no servidor de desenvolvimento os estilos de fonte Bootstrap estão substituindo meus estilos de tipografia. Isso é muito irritante porque preciso implantar o site para ver como ele realmente se parece. Se alguém souber como eu poderia ignorar o Bootstrap com typography.js no gatsby development, eu realmente apreciaria

Corrigido isso apenas reconstruindo o Bootstrap com o que eu queria

Mesmo problema aqui - https://github.com/gatsbyjs/gatsby/issues/16075

Estou tendo um problema semelhante ao que foi descrito aqui. Embora eu não esteja usando nenhuma estrutura CSS (todas personalizadas .sass), alguns estilos, elementos e classes são processados ​​de maneira diferente entre gatsby develop e gatsby build .

Isso está ocorrendo em uma página onde estou verificando os parâmetros de pesquisa usando URLSearchParams(window.location.search) . Com isso, estou exibindo dinamicamente um elemento dependendo da existência ou não de um parâmetro. Ao acessar diretamente a URL em develop , tudo funciona bem. Em build , tudo é tratado de forma bastante diferente.

Esperado ( develop ) :

Real ( build ) :

Lógica condicional :

{(!!params ? !params.has('signup') : true) && (
    <div className={[ styles.form__element, styles.contact__message, ].join( ' ')}>
        <label htmlFor="message">
            Message
            <textarea required minLength="10" name="message" id="message" cols="30" rows="10" className={styles.form__control} placeholder="Questions, comments, etc..." />
        </label>
    </div>
)}

params é definido por :

const params = typeof window !== `undefined` ? new URLSearchParams(window.location.search) : ''

System:
    OS: macOS 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.15.3 - /usr/local/bin/node
    npm: 6.10.2 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.100
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.13.50 => 2.13.50
    gatsby-image: ^2.2.8 => 2.2.8
    gatsby-plugin-google-analytics: ^2.1.6 => 2.1.6
    gatsby-plugin-hotjar: ^1.0.1 => 1.0.1
    gatsby-plugin-manifest: ^2.2.4 => 2.2.4
    gatsby-plugin-offline: ^2.2.4 => 2.2.4
    gatsby-plugin-react-helmet: ^3.1.3 => 3.1.3
    gatsby-plugin-sass: ^2.1.4 => 2.1.4
    gatsby-plugin-sharp: ^2.2.9 => 2.2.9
    gatsby-plugin-sitemap: ^2.2.5 => 2.2.5
    gatsby-remark-external-links: 0.0.4 => 0.0.4
    gatsby-source-contentful: ^2.1.17 => 2.1.17
    gatsby-source-filesystem: ^2.1.8 => 2.1.8
    gatsby-transformer-remark: ^2.6.10 => 2.6.10
    gatsby-transformer-sharp: ^2.2.5 => 2.2.5
  npmGlobalPackages:
    gatsby-cli: 2.7.27

@ j-651 Parece que estou tendo o mesmo problema. Eu leio os dados do armazenamento local e renderizo os nomes das classes condicionalmente, e os nomes das classes errados são renderizados. Alguma solução alternativa?

@OrKoN o que acabei fazendo para contornar esse problema foi criar uma página separada usando as peças originais como um componente e, em seguida, passar um objeto para renderizar condicionalmente, se isso fizer sentido. Não tenho certeza se isso funciona para sua implementação.

Estou tendo um problema semelhante. Primeiro, eu estava tendo uma versão diferente por causa dos componentes estilizados. Eu adicionei o plugin gatsby-plugin-styled-components e eles se consertaram. Então percebi que o MaterialUI começou a quebrar, então adicionei gatsby-plugin-material-ui e ainda sem sorte. A IU do material ainda está quebrada na implantação.

Produção:

Dev (local)

Consegui reproduzir meu problema e isolar no repo https://github.com/gatsbyjs/gatsby/issues/16925, ele está relacionado ao comportamento do componente de link e provavelmente é um problema diferente

Esta não é uma solução adequada, mas só queria entrar em contato com uma solução rápida que eu precisava fazer para lançar um projeto.

Copiei e colei a saída de typography.js, coloquei em um arquivo .scss e me certifiquei de importá-lo depois de todo o resto, com uma pequena mensagem.

typographyjs-output.scss
Apenas ignore este arquivo por favor e obrigado!
Tive que extrair o CSS gerado por typography.js e colocá-lo aqui.
Por quê? Veja aqui: https://github.com/gatsbyjs/gatsby/issues/8560
A compilação de produção importa SCSS e css-in-js em uma ordem diferente de dev (não tenho certeza se é sempre uma ordem consistente).
Eu removi 'gatsby-plugin-typography' e importei o CSS que foi gerado a partir dele como uma folha de estilo normal.
Typography.js foi incluído no projeto desde o início e eu não esperava que causasse qualquer problema.
Então, sim - eu estilizei o resto do site com esses padrões sendo incluídos, então remover esse arquivo torna as coisas um pouco estranhas.

Uma solução terrível, mas funciona se você estiver em apuros.

Algo que acabei de perceber é que no carregamento inicial da página o CSS está quebrado, mas mude a página e depois volte para a página inicial novamente e o CSS funciona. É apenas no carregamento inicial da página que o CSS não parece certo e também carrega bem devagar

Com o Material-UI, tive uma chamada dupla para o gatsby-plugin-material-ui no gatsby.config.js. O carregamento inicial da página piscava e alguns estilos às vezes não eram adicionados. Agora ele funciona com a versão mais recente do plug-in e este módulo é exportado na matriz de plug-ins de gatsby.config.js:
, { resolve: 'gatsby-plugin-material-ui', // If you want to use styled components you should change the injection order. options: { // stylesProvider: { // injectFirst: true, // }, }, }

Alguém encontrou uma solução aqui? Estou vendo um estilo incorreto na produção (visualização da primeira página), embora o local seja adequado. Por exemplo. O componente tem jss13 e jss14 em produção, mas essas classes devem ser jss43 e jss45. Também estou vendo que a ordem dos estilos na cabeça é diferente, mas estou perdido em como resolver ... Eu também tenho os dois plug-ins incluídos, mas sem sorte:

plugins: [
    'gatsby-plugin-styled-components',
    'gatsby-plugin-material-ui',
];

@ocundale Para mim, a solução foi remover o método de estilização material-ui. Por exemplo, o código a seguir pode causar problemas ao enviar para produção. Não sei por que, mas uma vez que removi isso e coloquei esse estilo como css embutido, tudo funcionou como planejado.

const MyTab = styled(Tab)({
  border: '1px solid grey',
  borderRadius: '50px',
  fontSize: '12px',
  marginRight: '16px'
})

Consertado fazendo

<Tab style={{
 border: '1px solid grey',
  borderRadius: '50px',
  fontSize: '12px',
  marginRight: '16px'
}}>
...
</Tab>

OK, obrigado @ Skillz4Killz , agradeço a resposta rápida, parece uma pena, mas acho que vou recorrer ao mesmo método então. Felicidades!

Esta não é uma solução adequada, mas só queria entrar em contato com uma solução rápida que eu precisava fazer para lançar um projeto.

Minha correção temporária foi adicionar !important a cada linha no meu css para que não fosse substituído pelo css do modelo. Brutal.

@ gatsbyjs / core Este problema parece surgir em todo o repositório uma e outra vez em diferentes variações. # 3741 # 5100 # 9911 # 10370 # 12360 # 14601 # 17676 # 17728 (Tenho certeza de que há mais, estou descobrindo-os o tempo todo)

Este é um problema CRÍTICO, pois não tem uma solução alternativa clara, afeta sites de forma não determinística e costuma aparecer de "maneiras misteriosas", pois tem alguns efeitos colaterais muito indiretos. Alterar atributos do mesmo elemento HTML - especialmente class - é um caso de uso _muito_ comum.

Se o que é dito em # 14601 estiver correto, então este é um problema com a consolidação da função de hidratação introduzida no React 16.

Existe o # 10706 que apenas ajuda a descobrir esse problema mais cedo no modo de desenvolvimento, mas não o corrige, tanto quanto eu entendo.

Para qualquer pessoa que esteja passando por isso, consegui consertar sem usar CSS inline / important.
Não é uma abordagem planejada e parecia mais com sorte, na verdade, mas adicionei os plug-ins _gatsby-plugin-material-ui_ e _gatsby-plugin-styled-components_ junto com a atualização do Material-UI para as versões> 4 e não vejo mais os problemas.

{
  resolve: 'gatsby-plugin-material-ui',
  options: {
    stylesProvider: {
      injectFirst: true,
    },
  },
},
'gatsby-plugin-styled-components',

"@material-ui/core": "^4.0.0",
"@material-ui/icons": "^4.0.0",
"@material-ui/styles": "^4.4.1",

Consigo reproduzir o problema, pelo menos uma instância dele.

Crie um novo site gatsby a partir deste repositório, que foi inicialmente clonado do starter padrão : https://github.com/eyalroth/gatsby-hydrate-bug

Quase não tem dependências / plug-ins:

$ gatsby info
  System:
    OS: Linux 4.4 Ubuntu 16.04.6 LTS (Xenial Xerus)
    CPU: (4) x64 Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
    Shell: 4.3.48 - /bin/bash
  Binaries:
    Node: 10.16.0 - ~/n/bin/node
    Yarn: 1.17.3 - /usr/bin/yarn
    npm: 6.11.3 - ~/n/bin/npm
  Languages:
    Python: 2.7.12 - /usr/bin/python
  npmPackages:
    gatsby: ^2.15.22 => 2.15.22
    gatsby-plugin-offline: ^3.0.8 => 3.0.8
  npmGlobalPackages:
    gatsby-cli: 2.7.44

O site possui apenas 2 páginas e um layout. O layout é adicionado automaticamente às 2 páginas por meio de wrapPageElement (praticamente o mesmo código de gatsby-plugin-layout ). O layout envolve o conteúdo da página com um div que tem um atributo class definido para a hora atual, enquanto também acrescenta a hora como texto abaixo do conteúdo da página.

Ao construir (e disponibilizar) o site, navegando até o índice e inspecionando-o nas ferramentas do desenvolvedor, pode-se perceber que o tempo exibido na página não é o mesmo que no div class atributo:

Navegar para a segunda página corrigirá esse comportamento e você verá que o tempo será o mesmo entre o conteúdo da página e o atributo class :

Isso permanecerá assim enquanto você continuar navegando entre as páginas na mesma janela. Se você atualizar a página ou abri-la em uma janela, a inconsistência voltará; na verdade, você notará que o tempo no atributo class permanecerá o mesmo sempre que você atualizar (sugerindo que ele está armazenado em cache). "Hard refresh" (CTRL + F5) irá carregar a página corretamente.

Esta instância particular do problema ocorre apenas com gatsby-plugin-offline habilitado, e está afetando diretamente gatsby-plugin-layout e possivelmente qualquer outra implementação de wrapPageElement .

A única solução alternativa que consegui sugerir até agora é simplesmente substituir a função hidratar por renderizar :

// gatsby-browser.js
const ReactDOM = require('react-dom')

export function replaceHydrateFunction() {
    return (element, container, callback) => {
        ReactDOM.render(element, container, callback)
    }
}

Novamente, este é um problema com a reconciliação do método de hidrato , conforme discutido em várias questões no repositório React, como https://github.com/facebook/react/issues/10591 , https://github.com/ facebook / react / issues / 12713 , https://github.com/facebook/react/issues/13260.

Observe que isso pode introduzir uma penalidade de desempenho, pois todo o propósito por trás da "hidratação" é aumentar o desempenho em relação à renderização simples.

Estamos encerrando este problema em favor de https://github.com/gatsbyjs/gatsby/issues/17914 para manter as coisas organizadas.

@eyalroth Concordo que este é _realmente_ um problema que precisamos resolver. Vamos discutir isso em https://github.com/gatsbyjs/gatsby/issues/17914 e chegar ao fundo disso

Eu também tenho esse problema. o ambiente de desenvolvimento de Gatsby estava bom, mas em construção ao recarregar a página do problema. O estilo de className e até mesmo inline estava sendo removido de certas tags. O que me deixou com um div sem atributos, mas todos os filhos foram renderizados.

no entanto, quando mudei a rota usando o roteador de link gatsby em vez de atualização de página inteira. isso corrige o problema.

Isso me deixou louco por horas. Eu encontrei uma solução terrível, provavelmente não uma boa prática, mas funcionou por enquanto.

Mas eu mudei a tag (div) para (artigo)

De repente o

<div>

tornou-se

<article class="CartSummary-module--summary--3zJVn">

na construção

Também funcionou com ul e pré.

Obrigado pela louca solução @ stefantrinh1 - eu também estou tendo esse comportamento maluco de CSS

Se alguém quiser vê-lo replicado, tenho um repositório público e implantei as duas versões:

parece funcionar com a solução alternativa de article @ stefantrinh1
https://github.com/funkfinger/blog/tree/good
https://good.jaywiggins.com

não funciona
https://github.com/funkfinger/blog/tree/bad
https://bad.jaywiggins.com

Tive um problema semelhante ao tentar carregar condicionalmente um componente com base no valor do cookie. Claro, isso não funcionou porque você tem SSR em produção (mas não tenho certeza porque funciona no modo dev). De qualquer forma, o que acabei fazendo é embrulhar meu cheque dentro de useEffect e verificar qual componente renderizar quando o React assumir (reidratar) o cliente. Você pode usar componentDidMount() para componentes de classe. Depois de implementar isso, tudo funciona conforme o esperado.

Meu problema era que eu estava usando wrapPageElement e wrapRootElement em gatsby-browser.js mas não em gatsby-ssr.js . Depois que copiei o que tinha para gatsby-ssr.js coisas começaram a funcionar como esperado. Veja por favor @jlkiri a resposta: https://github.com/gatsbyjs/gatsby/issues/22113#issuecomment -597432337

Mesmo problema em 2020. Clicar em corrige o problema, mas o problema de recarga total está presente.
"gatsby": "^ 2.19.45",
"react-custom-scrollbars": "^ 4.2.1",

eu tenho o mesmo problema que emailnikola

25729

No meu caso, gatsby-plugin-minify estava causando esse problema, o que levou a compilação de produção a recarregar todos os estilos na compilação de produção.