Next.js: Travailler avec des fichiers css et scss externes

Créé le 19 oct. 2017  ·  38Commentaires  ·  Source: vercel/next.js

C'est un problème redondant que je connais, mais j'ai ouvert ce problème intentionnellement. Cela fait trois jours que je configure un passe-partout next.js (avec redux, redux-saga, ...) et cela fait deux jours que je suis coincé dans la configuration du chargement de fichiers css et scss externes. J'ai vérifié les exemples with-global-stylesheet et with-scoped-stylesheet-and-postcss , mais chacun d'eux présente des problèmes majeurs mentionnés dans les numéros précédents. J'ai vu trop de problèmes ouverts et fermés qui résolvent ce problème avec des hacks... Je pense que c'est une bonne idée qu'au lieu de laisser le problème pour trouver la meilleure solution, résolvez-le avec les solutions disponibles actuellement jusqu'à en trouver une meilleure. Parce que beaucoup ont ce problème maintenant et veulent le voir résolu maintenant !

Commentaire le plus utile

J'aimerais également souligner que personnellement, je n'aime pas le ton que les gens ont dans cette question.
Je comprends tout à fait que vous vouliez importer du CSS. Et nous sommes très conscients de cette demande. C'est pourquoi j'ai passé la semaine dernière à travailler sur la meilleure solution possible 👍
Plus à ce sujet bientôt. D'ici là, soyez gentils et joyeuses fêtes 🎅😄

Tous les 38 commentaires

Je suis d'accord, seul styled-jsx a un support propre (y compris le rechargement à chaud) et c'est ce qui m'empêche d'utiliser Next.js pour autre chose que lorsque j'ai besoin d'un prototypage rapide.

Je pense que la solution aux problèmes de portée des modules CSS par CSS est beaucoup plus propre, et avec les modules CSS, il est toujours possible de passer des classes aux composants enfants (essayez de mettre une classe non globale sur un SVG importé avec babel-plugin-inline-react-svg avec styled-jsx).

Cela et je préfère avoir des fichiers standardisés .css pour éviter autant que possible le verrouillage du framework et des fichiers CSS externes en production pour la mise en cache (et pour que les polyfills MQ comme Respond.js fonctionnent si vous avez la malchance de doivent encore prendre en charge IE8).

Massif +1
C'est une énorme frustration qu'une chose aussi simple qu'un css/scss externe soit presque impossible à réaliser avec next.js, ce qui le rend inutile pour 90% de mes applications.

Je travaille avec bootstrap, et j'ai besoin d'une configuration où il y aura une importation globale de css bootstrap, avec l'ajout de css à portée externe.

Bien que nous ayons réussi à faire fonctionner un stylet externe avec le style jsx 1 (webpack pour gérer la compilation), nous avons eu du mal à le comprendre sur le style jsx 2 depuis l'introduction du changement de gestion des fichiers css séparés.
Approche actuelle :

import ComponentStyles from './footer.styl';
...
      <style jsx>
        {ComponentStyles}
      </style>

Ce serait formidable de voir https://github.com/zeit/next.js/tree/master/examples/with-styled-jsx-scss travailler avec des fichiers scss externes.

Nous avons vécu la même épreuve lors de la mise en place de l'environnement.
Finalement, nous nous sommes installés avec une feuille de style globale avec scss+post css avec lost-grid.
Le rechargement à chaud fonctionne, donc même si ce n'est pas une solution idéale (en raison du chargement de la feuille de style globale en même temps), c'est un bon compromis.

Dépendances

"autoprefixer": "^7.1.6",
"babel-plugin-module-resolver": "^2.7.1",
"babel-plugin-wrap-in-js": "^1.1.1",
"node-sass": "^4.5.3",
"sass-loader": "^6.0.6",
"pixrem": "^4.0.1",
"postcss-easy-import": "^3.0.0",
"postcss-loader": "^2.0.8"

En package.json

  ...
  "postcss": {
    "plugins": {
      "lost": {},
      "postcss-easy-import": {
        "prefix": "_"
      },
      "autoprefixer": {},
      "pixrem": {}
    }
  }
  ...

En next.config.js

webpack: (config, { dev }) => {
    config.module.rules.push(
      {
        test: /\.(css|scss)/,
        loader: 'emit-file-loader',
        options: {
          name: 'dist/[path][name].[ext]'
        }
      }
    ,
      {
        test: /\.css$/,
        use: ['babel-loader', 'raw-loader', 'postcss-loader']
      }
    ,
      {
        test: /\.s(a|c)ss$/,
        use: ['babel-loader', 'raw-loader', 'postcss-loader',
          { loader: 'sass-loader',
            options: {
              includePaths: ['styles', 'node_modules']
                .map((d) => path.join(__dirname, d))
                .map((g) => glob.sync(g))
                .reduce((a, c) => a.concat(c), [])
            }
          }
        ]
      }
    )
    return config
  }

En pages/_document.js

...

import stylesheet from 'styles/main.scss'

   ...
        <Head>
          <style dangerouslySetInnerHTML={{ __html: stylesheet }} />
        </Head>
   ...

Et vous pouvez ensuite gérer vos styles à partir de /styles/main.scss
J'espère que ça aide

Mon problème avec chacun de ces deux exemples de style ( with-global-stylesheet et with-scoped-stylesheets-and-postcss ) est qu'aucun d'entre eux n'est simple à intégrer aux tests Jest et Snapshot avec le CSS dans l'instantané. Il y a eu des gens qui ont réussi à faire fonctionner Jest avec Webpack, mais c'est en sautant spécifiquement le CSS.

L'exécution d'un fichier de préprocesseur babel-jest comme décrit dans cette réponse SO semble être un si mauvais hack.

Il semble que le CSS externe soit utilisé comme feuille de style with-global, vous devez utiliser Webpack, mais pour utiliser Jest, vous ne pouvez pas compter sur Webpack, uniquement sur Babel.

Quelqu'un a-t-il des idées dans cet espace?

Je suis confronté à un problème similaire. Je suis nouveau sur nextjs et je ne parviens pas à faire fonctionner correctement l'exemple "with-external-scoped-css". Parfois, mon css est chargé et parfois non. Je ne sais pas si c'est le même problème dont vous parlez.

https://github.com/zeit/next.js/issues/3276

Problèmes de styles externes résolus avec ce chargeur https://github.com/coox/styled-jsx-css-loader

@ilionic J'ai vérifié votre solution. C'est bien! Merci :)

@arefaslani Je ne pense pas que ce problème soit clos.

Depuis HTTP v1, c'est toujours une horrible taxe sur les performances pour des tonnes de CSS à charger, cela augmente considérablement le temps de premier dessin.

Une prise en charge correcte des styles externes permettrait d'importer du CSS et cela se traduirait par un pas une ligne