@ jonathan-chin pouvez-vous s'il vous plaît fournir des informations d'environnement pertinentes en exécutant gatsby info --clipboard ?

De plus, j'ai remarqué que vous utilisez Gatsby v1 à partir de votre package.json dans le dépôt que vous avez partagé. Veuillez utiliser gatsby-cli version 1.x.x pour Gatsby v1. gatsby-cli version 2.x.x est pour 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

lorsque je rétrograde mon gatsby-cli global vers 1.9.X, j'obtiens le problème CSS. quand je le garde à 2.0.0-rc.1, cela me donne l'erreur BrowserslistError: Unknown browser query dead

@ jonathan-chin Je comprends que vous rencontrez le problème CSS avec la version gatsby-cli 1.9.x , mais c'est la version que vous devriez utiliser car elle est compatible avec la version de Gatsby que vous utilisez.

Merci d'avoir partagé le repo de reproduction. Je vais y jeter un œil.

@ jonathan-chin serait-il possible pour vous de dire quel CSS est exactement différent en développement vs build?

@kakadiadarpan
Ceci est de développer et est le style attendu

voici ce que j'obtiens de build:

Vous pouvez voir que leurs classes CSS sont différentes.

Je ne me souviens pas que c'était un problème avant. La dernière bonne version (où CSS n'a pas été affecté) était https://gitlab.com/sharemeals/gatsby-site/commit/4342a715d6a1cdcb2808e5450819753be6f56a19

Je pense que le correctif pour cela est # 8092.

@ jonathan-chin seriez-vous capable d'extraire le contenu de ce correctif, puis d'essayer avec ces changements? Remarque: si vous ne l'avez pas encore vu, la section Comment contribuer de la documentation de Gatsby contient des informations sur la configuration de gatsby-dev-cli, dont vous aurez besoin pour le tester!

De plus, @ jonathan-chin ressemble à vous sur Gatsby v1. Seriez-vous capable de passer à Gatsby v2 pour obtenir ce correctif?

@DSchau désolé, il m'a fallu si longtemps pour y revenir.

la migration du projet existant vers la v2 était trop de travail. J'ai décidé de démarrer un nouveau démarreur v2 et de le migrer pièce par pièce (en copiant et en modifiant au besoin). Dans ce cas, gatsby develop produit une sortie radicalement différente de gatsby build:

Gatsby construire

gatsby développer

comparaison des styles css de deux éléments identiques lors de la construction et du développement:

construire:

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

développer:

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

J'ai des scss qui remplacent l'interface utilisateur matérielle que je charge dans le composant de mise en page dans la v2. en développement, il semble bien les fusionner mais en build, il semble les ignorer? cela peut-il en être la cause?

J'ai juste un import '../scss/style.scss';

@ jonathan-chin avez-vous essayé cela avec la v2 ou selon les étapes mentionnées dans le commentaire de @DSchau ci-dessus?

@kakadiadarpan Désolé, je n'ai pas la capacité (c'est-à-dire le temps) pour configurer ce flux de travail.

Après avoir examiné le correctif PR, il semble que ce soit le même problème que je rencontre. Je peux fermer ce problème pour l'instant et surveiller le PR.

@kakadiadarpan désolé, je viens de réaliser quelque chose d'étrange.

Lorsque mon site se charge pour la première fois, le CSS est farfelu. mais en le forçant à recharger la page d'index, le CSS se charge correctement. Voici les étapes à reproduire:

1) chargez https://sharemeals.org/
examinez la citation d'Emerson vers le bas:

2) cliquez sur le nom du site en haut à gauche. il rechargera la page d'index sans actualiser le site. la citation emerson apparaît comme prévu:

(la citation emerson indique d'autres changements CSS. J'appelle celle-ci uniquement parce qu'elle est la plus visible)

@ jonathan-chin Merci pour la mise à jour. Je suis en mesure de reproduire le problème avec les étapes que vous avez fournies. Utilisez-vous Gatsby v1 ou v2 pour https://sharemeals.org/?

~ J'ai exactement le même problème: ~

~ Lorsque vous utilisez injectGlobal j'obtiens des styles différents après avoir exécuté gatsby build . Vous pouvez voir le problème ici: https://ivorpad.com/about~

~ Une fois le chargement de la page terminé, passez la souris sur les liens «Écriture» ou «Travail» et vous verrez les styles changer. ~

Résolu le problème en déplaçant les styles de titre vers page.js au lieu 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 qui utilise "gatsby": "^1.9.277"

Je pense que le correctif pour cela est # 8092.

@ jonathan-chin seriez-vous capable d'extraire le contenu de ce correctif, puis d'essayer avec ces changements? Remarque: si vous ne l'avez pas encore vu, la section Comment contribuer de la documentation de Gatsby contient des informations sur la configuration de gatsby-dev-cli, dont vous aurez besoin pour le tester!

@ jonathan-chin pouvez-vous essayer les suggestions fournies par @DSchau dans ce commentaire?

@kakadiadarpan Je pense que j'ai essayé de mettre en œuvre cela tout à l'heure. J'ai installé gatsby-cli-dev, bifurqué et tiré, commuté la branche, etc. etc.

Le problème persiste.

Comment puis-je vérifier que le nouveau node_modules / gatsby que j'ai est correct et non l'ancien?

J'ai fait quelques recherches supplémentaires, avec Gatsby 1.XX et sans le correctif proposé.

(J'ai essayé de passer à Gatsby 2.XX et séparément le correctif proposé et aucun n'a fonctionné)

la classe jss pour le style souhaité existe sur la page initiale. dans ce cas, .jss58. Cependant, l'élément que je regarde n'obtient pas .jss58 sur le chargement initial. ce n'est qu'après avoir fait une autre demande de page (même en demandant la même page) que l'élément obtiendra correctement .jss58

Alors, qu'est-ce qui est chargé de déterminer quelles classes jss appliquer? y a-t-il une raison pour laquelle il aurait un résultat sur le chargement initial mais une charge différente sur toutes les demandes de page suivantes?

EDIT: il y a d'autres problèmes majeurs. sur la version de production, mes icônes svg ne se chargent jamais complètement, quelle que soit la demande de page:

C'est ce que j'obtiens à la place en développant:

Je suis confronté au même problème. Les versions gatsby develop et gatsby build sont très différentes pour moi.

Si j'atterris directement ou actualise une page avec des composants material-ui, le CSS est cassé pour ces composants. Les classes sont présentes dans la source mais elles ne sont pas appliquées aux éléments. Si je suis un <Link> sur la même page, cependant, tout fonctionne bien.

J'ai également remarqué que si j'exécute gatsby build pendant que gatsby develop est en cours d'exécution, la version de développement de gatsby commence également à se comporter exactement de la même manière que la version de construction de 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

(Je n'ai jamais utilisé gatsby-plugin-offline)

Vous pouvez consulter le site Web à l'adresse http://pawanhegde.netlify.com
La source est à https://gitlab.com/PawanH/pawanh.gitlab.io/tree/gatsbyjs

Pour voir la version "attendue", cliquez sur l'une des grandes icônes comiques en bas.

Je n'ai pas encore eu le temps d'essayer le correctif pour # 8092

Je n'ai pas encore eu le temps d'essayer le correctif pour # 8092

Cela n'a pas résolu le problème pour moi. Je vois toujours le même comportement.

Attendu

Réel

Si j'atterris directement ou actualise une page ... le CSS est cassé pour ces composants. Les classes sont présentes dans la source mais elles ne sont pas appliquées aux éléments. Si je suis un <Link> sur la même page, cependant, tout fonctionne bien.

Cela se produit également exactement comme décrit pour moi. J'ai essayé le correctif sur https://github.com/gatsbyjs/gatsby/pull/8092 et cela a fonctionné pour la plupart des pages, mais n'a pas fonctionné pour toutes.

Attendu:

Réel:

  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 

J'ai résolu ce problème en procédant comme suit
dans le fichier index.js que j'avais

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

en inversant l'ordre, j'ai pu spécifier l'ordre dans lequel je voulais importer des css dans le html.
Donc, mon code final était

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

Solution : modifier l'ordre des importations
Cela a résolu le problème pour moi. J'espère que cela vous fera de même.

J'ai les mêmes problèmes, parmi tant d'autres:

• develop s'exécute de manière non déterministe, cependant, lorsqu'il s'exécute, cela fonctionne très bien.
• StaticQuery ne parvient pas à terminer le chargement des images de manière non déterministe.
• build échoue de manière non déterministe, généralement seg en faute dans les images.
• build sortie de develop - c'est le facteur décisif.
• develop et build semblent interagir les uns avec les autres.

Ces problèmes sont tellement pénibles qu'ils semblent malheureusement l'emporter sur les avantages de Gatsby pour moi, et m'obligent à revenir à Create React App.

J'ai essayé diverses solutions de contournement comme la suppression de tous les styles en ligne et l'importation de .scss dans les composants enfants plutôt qu'au niveau racine.
Le problème persiste. C'est vraiment troublant

J'utilise des composants stylisés, ajouter gatsby-plugin-styled-components dans gatsby-config.js fonctionné pour moi.

Avoir le même problème.
La construction de Gatsby applique un nom de classe différent, mais je peux voir que la classe appropriée de l'inspecteur React est appliquée.

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!

Ce problème est devenu silencieux. Silencieux effrayant. 👻

Nous recevons beaucoup de problèmes, donc nous clôturons actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.

Si nous avons manqué ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette «non périmé» pour garder ce problème ouvert!

Merci de faire partie de la communauté Gatsby! 💪💜

Veuillez rester ouvert.

Le problème n'est toujours pas résolu. Veuillez rester ouvert un peu

  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

Le problème n'est toujours pas résolu. Veuillez rester ouvert un peu

  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

Comme indiqué dans https://github.com/gatsbyjs/gatsby/issues/11072, le problème doit être résolu dans 7058a256d2dcfab91259bdf00e811375737414e7.

Ce n'est que dans mon cas d'utilisation spécifique que @emotion/global été utilisé pour insérer un style global dans l'application. D'une manière ou d'une autre, les problèmes de fractionnement de code persistaient toujours en combinaison avec les fonctionnalités @emotion/global .

Solution de contournement

Les étapes suivantes ont été prises pour résoudre les problèmes. Ce n'est pas une solution parfaite mais cela a fonctionné dans cette configuration.

1. Mise à jour vers la dernière version de Gatsby ^2.1.8
2. Découvrez où import { Global, css } from '@emotion/core' est utilisé et déplacez le style CSS dans un nouveau fichier ./styles/global.css
3. Incluez la feuille de style dans votre version de production en ajoutant gatsby-brower.js à la racine du projet

// gatsby-brower.js

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

1. Nettoyer l'ancien cache et créer le dossier rm -rf .cache && rm -rf public
2. gatsby build -> gatsby serve
3. Voilá 💁‍♂️

Remarques

• Je soupçonne que beaucoup de problèmes ci-dessus sont causés par des moyens inhabituels d'insérer des styles (globaux) VS des problèmes de partage de code CSS mentionnés dans https://github.com/gatsbyjs/gatsby/issues/11072
• La solution de contournement ci-dessus est probablement un correctif de cas d'utilisation spécifique.
• Ce tutoriel sur le style dans Gatsby m'a aidé à le résoudre

C'est un problème frustrant.

Pour moi, les animations réalisées avec react-pose notamment dans gatsby-browser.js et gatsby-ssr.js faisaient des trucs vaudous étranges, un double rendu et des trucs css indéterministes où la page fonctionnerait sur un deuxième rafraîchissement.

Je ne peux toujours pas indiquer le problème exact, mais inspecter et éventuellement supprimer les plugins, supprimer les bibliothèques, le _solu_.

Bien que Gatsby, aux côtés d'autres outils JS, puisse être génial et flashy, soyez prudent et responsable de (ne pas) l'utiliser en production.

est-il possible de partager une nouvelle reproduction? Parce que lorsque vous utilisez css-in-js, cela peut être quelque chose que nous ne pouvons pas réparer car ce n'est pas de notre faute.

J'ai également rencontré ce problème.

J'ai ajouté typography.js a quelques jours. Ensuite, j'ai réalisé que les styles basés sur typography.js fonctionnent bien dans gatsby develop , mais ils ne sont pas disponibles dans gatsby build . J'ai créé les applications à partir du modèle de démarrage,

J'ai essayé de mettre à jour la version, cela ne fonctionne pas.
Ensuite, j'ai trouvé qu'il y avait un layout.css

Ma solution est de commenter layout.css et cela semble résoudre ce problème

Projet après l'ajout de typography.js
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/ffb52973c21014b247a808e444319f8eede6eee6

Projet après avoir commenté layout.css
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/658c7f8976d8d84a1fd28cb9aa6c99bbce2be9b3

@Jasonlhy C'était exactement le problème pour moi. Le fichier layout.js dans mon dossier de composants importe le fichier layout.css. Une fois que j'ai supprimé cette importation et exécuté à nouveau npm run build et npm run serve , le site s'est montré très bien. Merci beaucoup!

est-il possible de partager une nouvelle reproduction? Parce que lorsque vous utilisez css-in-js, cela peut être quelque chose que nous ne pouvons pas réparer car ce n'est pas de notre faute.

Salut @wardpeet , cela vient juste d'apparaître dans un de mes projets lorsque j'ai ajouté gatsby-plugin-styled-components, alors voici une nouvelle reproduction du problème qui continue de se produire sur Gatsby mis à jour:

EDIT: Il s'avère que je n'ai plus de reproduction, car le problème ne cesse de changer à mesure que j'édite mes styles. Après avoir déployé mon prochain commit, l'ordre des importations a de nouveau changé. Mon CSS est maintenant le même en développement et en production. Les captures d'écran et la description ci-jointes montrent ce qui se passait auparavant ...

La description

Gatsby commande les <head> différemment en développement et en production. Lorsque vous utilisez des composants gatsby-plugin-styled avec du CSS global, cela peut entraîner une différence dans l'ordre de chargement CSS entre le développement et la production, entraînant des bogues visuels inattendus.

Ceci est identique à # 9908, qui a été fermé avec une série de problèmes similaires en faveur de # 9733, qui à son tour a été fermé parce que par @KyleAMathews, il a été corrigé dans # 11800. Cependant, je vois toujours le comportement de # 9908 après m'être assuré que Gatsby est mis à jour.

Étapes à suivre pour reproduire

J'ai un exemple en direct (mais non minimal) du problème dans ce dépôt: https://github.com/vivshaw/vivshaw. Ce site a un morceau de CSS global comprenant le framework Bulma CSS, puis le reste du site est fait dans des composants stylisés. La version de production est en ligne sur netlify .

Résultat attendu

Les deux gatsby develop et gatsby build gatsby serve devraient se ressembler. L'ordre de chargement des styles doit être cohérent.

Résultat actuel

Une fois construits pour la production, nous voyons le style de page correct:

Mais lorsque nous le chargeons avec gatsby develop , le remplissage de la section intro est devenu AWOL:

J'ai creusé et j'ai compris pourquoi. En production, Gatsby charge le bloc css global avant les styles des composants stylisés, comme visible avec les deux lignes en surbrillance ici:

Mais en développement, les styles de composants stylisés se chargent en premier:

Pourquoi cela cause-t-il un bug? Eh bien, j'ai le composant étiqueté avec une classe Bulma et une classe générée par des composants stylisés. Les deux classes affectent les propriétés de remplissage, donc celui qui est chargé en dernier est celui qui est appliqué. Dans ce cas, il est facilement résoluble en supprimant simplement la classe Bulma. Mais je peux imaginer des situations dans lesquelles ce comportement d'ordre de chargement provoque des problèmes plus complexes.

Environnement

> 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

Merci certainement, ne sachant pas comment nous pourrions résoudre ce problème, nous pourrions vouloir ajouter une sorte de tri aux composants principaux.

Voir le même genre de problèmes que ceux mentionnés ci-dessus par @topherauyeung

Environnement

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

Avoir ce problème aussi. Nous avons un référentiel gatsby qui extrait les composants d'une bibliothèque NPM. Les composants importent des fichiers .scss qui sont injectés dans <head> dans le mauvais ordre lors de la construction. Lors du développement, les styles du référentiel gatsby viennent en dernier, ils ont donc la priorité, mais lors de la construction, ils viennent en premier et sont remplacés par les styles du composant importé.

J'ai un problème similaire peut-être lié à cela, je charge les styles de manière dynamique, sur gatsby develop les styles sont relatifs à la mise en page actuelle, sur gatsby build tous les styles à l'intérieur de 'source.less' sont également appliqués à la mise en page de l'application

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

J'ai également trouvé ce problème. Mais mon cas était une simple erreur.
J'utilisais

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

Quand j'ai changé pour utiliser Gatsby Link, cela fonctionne

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

Même problème. Garder un œil sur une solution pendant que j'essaye de déboguer.

En ajoutant à cela parce que je pense que c'est lié, mais que cela n'a été un problème que récemment:
J'utilise Typography.js ainsi que Bootstrap - en production, le bootstrap est remplacé par typography.js, ce que je veux, mais sur le serveur de développement, les styles de police Bootstrap remplacent mes styles de typographie. C'est assez exaspérant car je dois déployer le site pour voir à quoi il ressemble vraiment. Si quelqu'un sait comment je pourrais remplacer Bootstrap avec typography.js dans gatsby develop, je l'apprécierais vraiment

En ajoutant à cela parce que je pense que c'est lié, mais que cela n'a été un problème que récemment:
J'utilise Typography.js ainsi que Bootstrap - en production, le bootstrap est remplacé par typography.js, ce que je veux, mais sur le serveur de développement, les styles de police Bootstrap remplacent mes styles de typographie. C'est assez exaspérant car je dois déployer le site pour voir à quoi il ressemble vraiment. Si quelqu'un sait comment je pourrais remplacer Bootstrap avec typography.js dans gatsby develop, je l'apprécierais vraiment

Correction de cela en reconstruisant simplement Bootstrap avec ce que je voulais

Même problème ici - https://github.com/gatsbyjs/gatsby/issues/16075

Je rencontre un problème similaire à celui décrit ici. Bien que je n'utilise aucun framework CSS (tous .sass personnalisés), certains styles, éléments et classes sont traités différemment entre gatsby develop et gatsby build .

Cela se produit sur une page où je vérifie les paramètres de recherche en utilisant URLSearchParams(window.location.search) . Avec cela, je montre dynamiquement un élément selon qu'un paramètre existe ou non. Lorsque vous accédez directement à l'URL sur develop , tout fonctionne correctement. Sur build , tout est géré différemment.

Attendu ( develop ) :

Réel ( build ) :

Logique conditionnelle :

{(!!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 est défini par :

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 Je semble avoir le même problème. Je lis des données à partir du stockage local et rend les noms de classe conditionnellement, et les mauvais noms de classe sont rendus. Des solutions de contournement?

@OrKoN ce que j'ai fini par faire pour contourner ce problème a été de créer une page séparée en utilisant les pièces d'origine comme composant, puis de passer un accessoire pour un rendu conditionnel, si cela a du sens. Je ne sais pas si cela fonctionne pour votre implémentation.

J'ai un problème similaire. Tout d'abord, j'avais une version différente en raison de composants stylisés. J'ai ajouté le plugin gatsby-plugin-styled-components et ceux-ci se sont corrigés. Ensuite, j'ai remarqué que MaterialUI commençait à se casser alors j'ai ajouté gatsby-plugin-material-ui et toujours pas de chance. L'interface utilisateur matérielle est toujours défectueuse lors du déploiement.

Production:

Dev (local)

J'ai pu reproduire mon problème et l'isoler dans le repo https://github.com/gatsbyjs/gatsby/issues/16925 il est lié au comportement du composant de lien et c'est probablement un problème différent

Ce n'est pas une solution appropriée, mais je voulais juste ajouter une solution rapide avec laquelle je devais aller pour faire sortir un projet.

J'ai copié et collé la sortie de typography.js, je l'ai placée dans un fichier .scss, et je me suis assuré de l'importer après tout le reste, avec un petit message.

typographyjs-output.scss
Ignorez simplement ce fichier et merci!
J'ai dû extraire le CSS généré par typography.js et le placer ici.
Pourquoi? Voir ici: https://github.com/gatsbyjs/gatsby/issues/8560
La version de production importe SCSS et css-in-js dans un ordre différent de dev (je ne sais pas si c'est toujours un ordre cohérent).
J'ai supprimé 'gatsby-plugin-typography' et importé le CSS qui a été généré à partir de celui-ci comme une feuille de style classique.
Typography.js a été inclus dans le projet depuis le début et je ne m'attendais pas à ce que cela pose un problème.
Alors oui - j'ai stylisé le reste du site avec ces valeurs par défaut incluses, donc la suppression de ce fichier rend les choses un peu bizarres.

Solution assez terrible mais cela fonctionne si vous êtes dans une impasse.

Quelque chose que je viens de réaliser, c'est que lors du chargement initial de la page, le CSS est cassé, mais changez la page, puis revenez à la page d'accueil et le CSS fonctionne. Ce n'est qu'au chargement initial de la page que le CSS n'a pas l'air correct et se charge également assez lentement

Avec Material-UI, j'ai eu un double appel pour gatsby-plugin-material-ui dans le gatsby.config.js. Le chargement initial de la page avait un scintillement et certains styles n'étaient parfois pas ajoutés. Maintenant, il fonctionne avec la dernière version du plugin et l'exportation de ce module dans le tableau des plugins 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, // }, }, }

Quelqu'un a-t-il trouvé une solution ici? Je vois un style incorrect lors de la production (vue de la première page), même si local est bien. Par exemple. Le composant a jss13 et jss14 en production, mais ces classes doivent être jss43 et jss45. Je vois également que l'ordre des styles dans la tête diffère, mais je suis perdu quant à la façon de résoudre ... J'ai aussi les deux plugins inclus, mais pas de chance:

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

@ocundale Pour moi, le correctif était de supprimer la méthode de style material-ui. Par exemple, le code suivant provoquerait des problèmes lors de la mise en production. Je ne sais pas pourquoi, mais une fois que j'ai supprimé cela et mis ce style en css en ligne, tout a fonctionné comme prévu.

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

Corrigé en faisant

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

OK, merci @ Skillz4Killz , appréciez la réponse rapide, cela semble dommage, mais je pense que je vais alors utiliser la même méthode. À votre santé!

Ce n'est pas une solution appropriée, mais je voulais juste ajouter une solution rapide avec laquelle je devais aller pour faire sortir un projet.

Ma correction temporaire ajoutait !important à chaque ligne de mon css afin qu'il ne soit pas remplacé par le modèle css. Brutal.

@ gatsbyjs / core Ce problème semble surgir partout dans ce référentiel à maintes reprises dans différentes variantes. # 3741 # 5100 # 9911 # 10370 # 12360 # 14601 # 17676 # 17728 (je suis sûr qu'il y en a d'autres, je les découvre tout le temps)

Il s'agit d'un problème CRITIQUE, car il n'a pas de solution de contournement claire, affecte les sites de manière non déterministe et apparaît souvent de «manière mystérieuse» car il a des effets secondaires très indirects. Changer les attributs du même élément HTML - en particulier class - est un cas d'utilisation très courant.

Si ce qui est dit dans # 14601 est correct, alors c'est un problème avec la consolidation de la fonction d'hydratation introduite dans React 16.

Il y a # 10706 qui aide seulement à découvrir ce problème plus tôt en mode développement, mais cela ne le résout pas, pour autant que je sache.

Pour toute autre personne expérimentée, j'ai réussi à corriger sans utiliser de CSS / important en ligne.
Ce n'était pas une approche planifiée et je ressemblais plus à de la chance, mais j'ai ajouté les plugins _gatsby-plugin-material-ui_ et _gatsby-plugin-styled-components_ avec la mise à niveau de Material-UI vers les versions> 4 et je ne vois plus les problèmes.

{
  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",

Je suis capable de reproduire le problème, au moins une instance de celui-ci.

Créez un nouveau site gatsby à partir de ce référentiel, qui a été initialement cloné à partir du démarreur par défaut : https://github.com/eyalroth/gatsby-hydrate-bug

Il a à peine des dépendances / plugins:

$ 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

Le site n'a que 2 pages et une mise en page. La mise en page est automatiquement ajoutée aux 2 pages via wrapPageElement (à peu près le même code que dans gatsby-plugin-layout ). La mise en page enveloppe le contenu de la page avec un div qui a un attribut class défini sur l'heure actuelle, tout en ajoutant également l'heure sous forme de texte sous le contenu de la page.

Lors de la construction (et de la diffusion) du site, en naviguant vers l'index et en l'inspectant dans les outils de développement, on peut voir que l'heure affichée dans la page n'est pas la même que dans le div class attribut:

Naviguer vers la deuxième page corrigera ce comportement, et vous verrez que l'heure sera la même entre le contenu de la page et l'attribut class :

Cela restera ainsi tant que vous continuez à naviguer entre les pages dans la même fenêtre. S'il vous arrive d'actualiser la page ou de l'ouvrir dans une fenêtre, l'incohérence disparaîtra; vous remarquerez en fait que l'heure de l'attribut class restera la même à chaque actualisation (indiquant qu'il est mis en cache). "Hard refresh" (CTRL + F5) chargera la page correctement.

Cette instance particulière du problème se produit uniquement avec gatsby-plugin-offline activé et affecte directement gatsby-plugin-layout , et peut-être toute autre implémentation de wrapPageElement .

La seule solution de contournement que j'ai pu proposer jusqu'à présent est de simplement remplacer la fonction hydrate par un rendu :

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

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

Encore une fois, il s'agit d'un problème avec la réconciliation de la méthode hydrate , comme indiqué dans plusieurs numéros du référentiel React, tels que https://github.com/facebook/react/issues/10591 , https://github.com/ facebook / react / issues / 12713 , https://github.com/facebook/react/issues/13260.

Notez que cela peut introduire une pénalité de performance, car tout le but derrière "l'hydratation" est d'augmenter les performances par rapport au rendu ordinaire.

Nous clôturons ce numéro en faveur de https://github.com/gatsbyjs/gatsby/issues/17914 pour garder les choses organisées.

@eyalroth Je suis d'accord qu'il s'agit _indeed_ d'un problème que nous devons résoudre. Discutons de cela dans https://github.com/gatsbyjs/gatsby/issues/17914 et allons au fond de cela

J'ai aussi eu ce problème. l'environnement de développement Gatsby fonctionnait bien mais en construction lors du rechargement de la page de problème. className et même le style en ligne étaient supprimés de certaines balises. Ce qui m'a laissé avec un div sans attributs mais tous les enfants ont été rendus.

Cependant, lorsque j'ai changé d'itinéraire en utilisant le routeur de lien gatsby plutôt que l'actualisation complète de la page. il résout le problème.

Cela m'a rendu fou pendant des heures. J'ai trouvé une solution horrible, probablement pas une bonne pratique, mais cela a fonctionné pour le moment.

Mais j'ai changé la balise (div) en (article)

Soudain, le

<div>

devenu

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

à la construction

Il a également fonctionné avec ul et pre.

Merci pour la solution de contournement folle @ stefantrinh1 - Moi aussi, je vis ce comportement css fou

Si quelqu'un veut le voir répliqué, j'ai un dépôt public et j'ai déployé les deux versions:

semble fonctionner avec la solution article contournement @ stefantrinh1
https://github.com/funkfinger/blog/tree/good
https://good.jaywiggins.com

ne marche pas
https://github.com/funkfinger/blog/tree/bad
https://bad.jaywiggins.com

J'ai eu un problème similaire en essayant de charger un composant en fonction de la valeur du cookie. Bien sûr, cela n'a pas fonctionné car vous avez SSR en production (vous ne savez pas pourquoi cela fonctionne en mode de développement). Quoi qu'il en soit, j'ai fini par emballer mon chèque dans useEffect et vérifier quel composant rendre une fois que React prend le relais (réhydrate) sur le client. Vous pouvez utiliser componentDidMount() pour les composants de classe. Après avoir mis en œuvre cela, tout fonctionne comme prévu.

Mon problème était que j'utilisais wrapPageElement et wrapRootElement dans gatsby-browser.js mais pas dans gatsby-ssr.js . Une fois que j'ai copié ce que j'avais sur gatsby-ssr.js choses ont commencé à fonctionner comme prévu. La réponse s'il vous plaît voir @jlkiri « : https://github.com/gatsbyjs/gatsby/issues/22113#issuecomment -597432337

Même problème en 2020. En cliquant sur corrige le problème, mais le problème de rechargement complet est présent.
"gatsby": "^ 2.19.45",
"react-custom-scrollbars": "^ 4.2.1",

j'ai le même problème que emailnikola

25729

Dans mon cas, gatsby-plugin-minify posait ce problème, ce qui a conduit la version de production à recharger tous les styles de la version de production.