Next.js: [RFC] Compatibilidad con CSS

Supongo que con complementos como @zeit/next-sass ya funcionan con la versión compatible actual de los módulos CSS, ¿ .module.scss también funcionaría? ¿O la frase "módulos CSS puros" significa solo .module.css ?

Para mí, el apoyo de Sass es perfecto para la mayoría de los proyectos.

Los complementos @zeit/next-css/sass/less/stylus quedarán obsoletos a favor de este RFC (soporte integrado). Todavía estamos discutiendo hasta qué punto el sass será parte del núcleo frente a un complemento. Mi pensamiento actual es que cuando agregas node-sass habilitará el soporte sass. Similar a lo que hacemos con TypeScript. La razón por la que no lo agregaremos como una dependencia es que es bastante grande y muy lento de instalar debido a los enlaces nativos, etc.

¡Esto es emocionante! ¡Me tropezaron con nombres de clases CSS en conflicto como hoy!

Pregunta, ¿cómo funciona con TypeScript? Una razón por la que no he habilitado el módulo css es que, al importar el módulo css, obtendría un objeto cualquiera (tal vez un poco mágico, como .foo-bar se convertirá en un campo llamado fooBar ?) que no es compatible con TS. Dado que Next ahora es TS por defecto, me imagino que podemos hacerlo mejor en este asunto.

No estoy seguro de si "Solucionar automáticamente errores flexibles conocidos para el usuario" será una buena idea.

Me temo que terminaremos en escenarios confusos donde las bibliotecas de componentes de terceros en npm, que incluyen hojas de estilo css, se comportarán de manera diferente en entornos nextjs que en otros (como create-react-app).

@TheHolyWaffle corrigiendo errores flexibles conocidos crea un comportamiento más predecible, y también es lo que hace la aplicación Create React.

@zenozen De acuerdo con la especificación de módulos CSS, class-name ), deberá acceder explícitamente a eso en el objeto.

p.ej

import Everything from './file.module.css'

// later on

Everything['class-name']

En cuanto a TS, no planeamos ninguna magia para manejar los tipos, pero es bastante fácil definir un tipo de TS para manejar estos archivos.

declare module '*.module.css' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.scss' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.sass' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

Hagamos lo que hagamos aquí, ¿podemos asegurarnos de que aún sea fácil de usar los complementos PostCSS personalizados como lo es ahora con @zeit/next-css ? Sería una verdadera lástima que perdiéramos el soporte para eso: CRA no admite esto y por eso es imposible usar herramientas como Tailwind CSS de una manera razonable.

Tendría cuidado con estas tres características a este respecto:

• Use Autoprefixer para agregar prefijos específicos del proveedor automáticamente (sin soporte de flexbox heredado)
• Polyfill o compile las características de CSS Stage 3+ con sus equivalentes
• Corrige automáticamente los "errores flexibles" conocidos para el usuario

... porque todo esto se hace con PostCSS, y es muy importante que el pedido del complemento PostCSS esté bajo el control del usuario final.

Sugeriría que si va a habilitar esos tres complementos de forma predeterminada, el usuario debería poder anular completamente la configuración de PostCSS predeterminada proporcionando su propio archivo postcss.config.js . Tendrían que agregar esos complementos manualmente si siguieran esta ruta, pero ese nivel de control es necesario en mi opinión.

TL; DR, tenga cuidado de no romper la capacidad de los usuarios de tener un control completo de PostCSS, literalmente no puedo usar CRA debido a esto y estaría muy triste si no pudiera usar Next.

Seconding @adamwathan : sería genial obtener más detalles aquí sobre cómo se vería la personalización de la opción postcss. Sería realmente bueno tener una opción para modificar la configuración de postcss a través del siguiente complemento, así como postcss.config.js , para que las configuraciones compartidas en múltiples proyectos se puedan inyectar fácilmente sin un archivo adicional.

Creo que es mejor habilitar los módulos css para todas las importaciones css (no solo para el sufijo .module ), y el que queremos que sea global necesitaremos especificar un sufijo .global .

Los módulos CSS serían geniales. Creo que mantener la especificación *.module.(css|scss) está bien, ya que se alinea con create-react-app , permite la mecanografía y permite migraciones más fáciles para otros usuarios nuevos en Next.js

Con mecanografiado, puede hacer cumplir las tipificaciones de módulos CSS generando *.d.ts tipificaciones para cada archivo *.(css|scss) usando typed-css-modules y typed-scss-modules pero si no quiere hacer eso y todavía desea el autocompletado, puede usar la siguiente extensión de VS Code:
https://marketplace.visualstudio.com/items?itemName=clinyong.vscode-css-modules

@adamwathan ¡tenga la seguridad de que permitiremos la configuración de PostCSS! No estamos seguros de cómo se verá la implementación _exact_ todavía, pero debería surgir de forma natural con la solicitud de extracción de CSS.

¡¡Esto es genial!! ¿Existe una línea de tiempo para esto? ¿Está sucediendo este año?

@andreisoare estamos a punto de fusionar la mitad global de este RFC: https://github.com/zeit/next.js/pull/8710

Continuaremos con el soporte de módulos CSS lo antes posible.

@adamwathan @Timer sería genial si pudiéramos continuar usando el archivo postcss.config.js convencional en la raíz del proyecto, como podemos ahora con next-sass .

Me alegro mucho de ver que esto llega al núcleo.

¿Esta RFC admitirá la representación de rutas críticas de AMP?

para el registro, si puede, debe usar styled-jsx porque le permite encapsular css, html y js en 1 idea, un componente. Si aún no se ha dado cuenta de esto (esta es una nota para los usuarios de next.js, no para los mantenedores), esto le permite no tener que comprar un kit de interfaz de usuario CSS completo como bootstrap, puede probar 1 componente y si no lo hace Si se adapta a sus necesidades, lo desecha sin la carga de lidiar con el equipaje de esa dependencia externa de CSS.

Creo que también es muy importante difundir este conocimiento porque CSS a menudo se malinterpreta o es una ocurrencia tardía y, a menudo, se convierte en la perdición del trabajo de los desarrolladores. Pero con la abstracción adecuada, en realidad puede ser bastante fácil razonar.

y sólo porque "mucha gente" esté importando su CSS no significa que sea una gran idea.

Creo que una de las cosas más poderosas de react es el hecho de que encapsula CSS, HTML y JS para ti. y si carga lateralmente (importa) el CSS, da un paso al costado que le brinda el beneficio react.

Para el registro: CSS-in-CSS (o HTML) es una capa de transporte mucho más eficiente para estilos, y colocar js y estilos en un archivo no es mejor que colocarlos en un directorio.
Aún más, la mayoría de CSS-in-JS de última generación extrae CSS a CSS en el momento de la compilación por motivos de rendimiento, por lo que la gestión adecuada de un CSS estático es imprescindible. Sin embargo, aún no se ha revelado la forma en que Next respaldaría dichas extracciones.

Para el registro: smile :: ¡Usar SASS, LESS con un Framework como Bootstrap sigue siendo una cosa y funciona realmente bien! La encapsulación no debe ocurrir en el nivel JS. Usar BEM es una alternativa. Apoyar en ambos sentidos es esencial.

@timer ¿La primera mitad de esto (https://github.com/zeit/next.js/pull/8710) significa que la división de rutas de CSS ahora funciona? ¿O aún está por llegar?

(Relacionado, https://github.com/zeit/next-plugins/issues/190)

CSS global no se puede dividir en ruta, así que no. Solo los módulos CSS (importados a nivel de componente) se dividirán en ruta. 👍

¿Existe una explicación de cómo esto afecta los problemas # 9392 y # 9385? Solo para entender lo que está sucediendo detrás de escena. Entonces, podría solucionar cómo solucionar los problemas en mi base de código.

Hola. Estamos buscando actualizar nuestra aplicación React a next.js principalmente para aprovechar las excelentes herramientas y la representación del lado del servidor.

Sin embargo, para nosotros es un requisito difícil poder utilizar módulos CSS. Probamos con el siguiente complemento para CSS, pero eso causó estragos con problemas como # 9392 # 9385 y más.

¿Existe alguna ETA para el soporte de módulos CSS (incluso experimental)? ¿Alguna forma de ayudar a acelerar su desarrollo?

¿Entonces no podemos importar css a nivel de componente?

Puede, solo necesita usar una solución alternativa ahora mismo hasta que se solucione el problema. Creo que puede encontrar uno que funcione para usted en el problema de next-css .

Perdón por la pregunta estúpida: en lo que respecta al CSS global, ¿en qué se diferencia o es mejor que solo incluir un enlace en la cabeza?

@otw si importa CSS global, pasa por la canalización de compilación con el resto de su código para que se minimice, etc. y luego se convierte en parte de la compilación y salida de next.js

Depende de ti si eso es una ventaja. Me imagino que la mayoría de la gente espera con ansias los módulos CSS para que el CSS necesario para un componente específico se cargue solo cuando el componente esté cargado.

Para el contexto, tenemos un equipo de desarrolladores que han estado usando NextJS durante los últimos dos años para crear casi 40 aplicaciones web para startups en etapa inicial.

Quiero aprovechar la oportunidad aquí para describir cómo diseñamos nuestras aplicaciones para mostrar las necesidades actuales, los puntos débiles, las advertencias sobre algunos npms requeridos que enfrentamos y cierta preocupación con los cambios propuestos.

Implementación actual

• Mantenemos una aplicación de "kit de inicio" que tiene muchas de las funciones de nuestra aplicación principal preconstruidas. Se clona como punto de partida, ya que contiene una gran cantidad de funcionalidades extendidas simplemente usando Bootstrap.
• Usamos Bootstrap y Reactstrap como base de nuestro sistema de diseño. Debido a que queremos un sistema de diseño cohesivo, estamos usando SASS global con las pautas de Bootstrap para extender el sistema de diseño e incorporar nuestras propias adiciones en las formas de opciones de configuración adicionales, mixins, funciones, etc. Todo esto se implementa mediante la importación de patrones en un archivo sass. cargado globalmente sin módulos css a través del ejemplo estándar next-sass de NextJS. Captura de pantalla: http://prntscr.com/qc8r0g.
• Para muchos de nuestros proyectos, podemos obtener estilos principalmente mediante las clases de utilidad proporcionadas por nuestra configuración extendida de Bootstrap, sin embargo, hay excepciones. Para esas excepciones, usamos el complemento SASS con styled-jsx . La razón por la que usamos el complemento SASS es que importamos nuestras variables de arranque, funciones y mixins de nuestros globales para mantener la coherencia del sistema de diseño. Hicimos una importación especial llamada "jsx-helper" que los incorpora a nuestro styled-jsx. Captura de pantalla: http://prntscr.com/qc8xbr.
• En el caso de algunos componentes de diseño que necesitan tocar las etiquetas html, body y root div, algunos complementos que generan su propio marcado, o npms que utilizan portales y necesitan CSS para tocar el marcado no accesible desde el componente, usamos la opción global con estilo. -jsx. Este es un último recurso, pero es necesario para nuestro componente de diseño, como puede ver aquí: http://prntscr.com/qc8yo6

Inconvenientes / problemas actuales

• Preferiríamos no usar código SASS inyectado (problemas IDE y falta de soporte con lenguajes inyectados) con nuestros componentes, pero el ejemplo de usar un archivo sass externo con styled-jsx no funciona cuando se importan variables de arranque debido a un error de compilación conocido con required npm stylis . El proyecto parece no admitido en este punto, por lo que recomendaría encarecidamente que no esté en ninguna cadena de herramientas propuesta por NextJS.
• Los cambios en nuestras variables globales de SCSS importadas a nuestro styled-jsx SASS no se detectan. De hecho, hay algún tipo de caché de módulo npm global que no podemos borrar que parece hacer que el paquete web no pueda recargar en caliente los cambios que se propagan desde nuestras variables globales de Bootstrap. Haciendo un npm ci completo para reconstruir la carpeta node_modules , borrando la caché del navegador, el comando de la consola cache clear force no funciona porque hay algo de caché npm global como funciona aquí. Por lo tanto, nos gustaría mucho que la recarga en caliente funcione correctamente al actualizar archivos importados en módulos CSS / SASS aplicados a componentes. En resumen, cualquier procesamiento SASS realizado por componentes debe estar atento a los cambios en las importaciones y mantener la recarga en caliente en funcionamiento. Esto se habría resuelto con la opción de cargador de paquetes web que se indicó en el punto anterior.
• Tuvimos que encontrar una solución para compartir nuestra configuración de PostCSS en dos lugares separados, ya que SASS global y styled-jsx se construyen por separado.

Inquietudes con los cambios propuestos

Estamos un poco preocupados con la idea de bloquear la opción global con los módulos de componentes CSS / SASS, ya que tenemos algunos casos de uso que necesitan, según el componente, tocar las etiquetas html, body y root div, así como casos de HTML generado. eso no necesariamente existe dentro de dicho componente debido a la ubicación a través de portales, etc. Creo que podríamos solucionar algo de esto con SASS global y algo de reestructuración para que no dependamos de qué componente se carga para aplicar CSS global específico.

Queremos un control total sobre PostCSS y preferiríamos no tener que lidiar con la obligación de aplicar un conjunto específico de valores predeterminados.

Lo siento, esta fue una respuesta larga, pero creo que tenemos algunas ideas que vale la pena compartir. ¡No dude en hacerme saber si tiene alguna pregunta y estamos ansiosos por ver qué se les ocurre a los equipos de NextJS a continuación (juego de palabras)!

@Soundvessel ,

Estamos un poco preocupados con la idea de bloquear la opción global con los módulos CSS / SASS de componentes, ya que tenemos algunos casos de uso que necesitan, según el componente, tocar las etiquetas html, body y root div, así como casos de HTML generado. que no necesariamente existe dentro de dicho componente

Si te entendí correctamente, aún deberías poder lograrlo usando :global en módulos CSS.

@ Daniellt1

Si te entendí correctamente, aún deberías poder lograrlo usando :global en módulos CSS.

Vea su nota arriba

El especificador de módulos CSS está permitido cuando se combina con un nombre de clase local

En el caso de nuestro componente de diseño, estamos apuntando a <html> , <body> y root div sin un nombre de clase local.

También se mencionó en un video sobre este tema que están considerando bloquear la opción :global completo, lo que no tiene sentido para mí considerando la gran cantidad de npms y API de CMS que generan marcas que no se pueden tocar. por módulos CSS con ámbito.

Hola @Soundvessel : este es mi video que grabé internamente para mi equipo (¿cómo

También me gustaría agradecerle por proponer una solución que permite el uso de CSS / SASS en lugar de un JS complicado en una solución CSS que requiere una sintaxis adicional como propiedades camelCased, etc. Muchos de nosotros venimos de una solución más centrada en el diseño. antecedentes, tener años de experiencia trabajando directamente con HTML / CSS, y nos facilita no tener que trasponer lo que estamos viendo en el código con demasiada profundidad a lo que estamos depurando en la pantalla.

Solo quiero agregar, a menos que me haya perdido alguna mención anterior, que la detección / habilitación automática de Sass es genial, pero las opciones de la API de Sass también deben exponerse en algún lugar: [email protected] ha establecido un buen patrón que incluye permitir la el usuario debe elegir qué motor sass aplicar; sus opciones podrían tomarse 1: 1 ...

Me gustaría proponer que la extensión para módulos CSS sea configurable.
¿Quizás exponer una matriz para admitir más de una extensión que no sea .module.css ?
Para algunos desarrolladores, crear un archivo .module.css e importarlo import "Component.module.css" cuando tienes muchos componentes nos parece un poco abultado.

En mi caso, me gustaría poder crear un archivo con la extensión: .m.css , digamos Component.m.css e importarlo como import "Component.m.css"

A menos que el equipo de Next.js diga que existen algunas dificultades técnicas que impiden que esto se haga.

No creo que se deba abrir ninguna configuración para nombrar extensiones, ya que parece un aumento innecesario de la huella, pero cuestiono la _necesidad_ de la extensión .module.css si esto será parte de la implementación:

Next.js solo le permitirá importar CSS global dentro de páginas personalizadas / _app.js.

Inicialmente pensé que .module.css sería necesario para que la compilación detecte lo que debería analizarse como módulos CSS y lo que no debería ser, pero si se importan no módulos en cualquier componente / página fuera de _app.js se producirá un error y se romperá la construcción, entonces la convención de nomenclatura no debería ser necesaria, ya que cualquier cosa importada fuera de _app.js debería ser un módulo CSS por naturaleza.

¿Se está forzando esto simplemente como una convención en lugar de una necesidad?

La elección de la convención module.css choca con el convento ya establecido por https://github.com/css-modules/css-modules
Ejemplos aquí:
https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
y aquí:
https://www.gatsbyjs.org/docs/css-modules/

Sí, probablemente hacer configurable la extensión podría complicarlo más de lo necesario. Pero al menos podría definir .module.css en un archivo constante y no codificado en varios lugares para cambiarlo mediante parches de mono

@bySabi

La diferencia entre esta implementación propuesta y create-react-app es que la importación de una "hoja de estilo normal" como el ejemplo que vinculó con another-stylesheet.css no estaría permitido en absoluto. En ese caso, .module.css se usa para determinar qué hoja de estilo debe ser manejada de qué manera por las herramientas de construcción.

La especificación de módulos CSS no establece ninguna convención de nomenclatura.

Sé que los módulos CSS no establecen ninguna convención sobre la extensión de los archivos sino sobre cómo se importan los módulos.

A donde quiero ir es que .module.css son las convenciones elegidas por los equipos de Next.js y deberían "facilitar" la posibilidad de que algunos usuarios puedan cambiarlo incluso si es a través de un módulo posterior a la instalación que hace monkey patching

Creo que .module.css es la primera convención de nomenclatura |

La elección de la convención module.css choca con el convento ya establecido por css-modules / css-modules
Ejemplos aquí:
create-react-app.dev/docs/adding-a-css-modules-stylesheet
y aquí:
gatsbyjs.org/docs/css-modules

Sí, probablemente hacer configurable la extensión podría complicarlo más de lo necesario. Pero al menos podría definir .module.css en un archivo constante y no codificado en varios lugares para cambiarlo mediante parches de mono

Estás contradiciendo tu punto aquí, .module.css está siendo utilizado por create-react-app y gatsby para la misma función. Es un patrón establecido.

Sin embargo, cambiar la convención de nomenclatura no es un patrón establecido y no hay razón para permitirlo en Next.js.

Creo que .module.css es la primera convención de nomenclatura | extensión impuesta por Next.Js. Por favor corrígeme si estoy equivocado.

Next.js establece convenciones sobre las opciones de configuración, por ejemplo:

• pages directorio siendo rutas
• pages/api siendo rutas API
• soporte para .js .tsx .tsx

Hola @timneutkens

El patrón está en cómo CSS Modules establece cómo se deben importar los archivos CSS a los objetos JS, el nombre del CSS en cuestión es marginal. En ese sentido, Next.js no está usando ese patrón en particular con la nueva implementación.
El CSS Modules como en Gatsby y CRA ya se implementaron en Next antes: https://github.com/zeit/next-plugins/tree/master/packages/next-css

No cuestiono la convención utilizada, .module.css , incluso sabiendo que podría confundir a los usuarios de CRA y Gatsby con CSS Modules . Elegir un nombre adecuado es difícil y no todo el mundo siempre está contento.

Aunque creo que la convención .m.css es mejor porque es más corta (más adecuada para una extensión) y menos redundante (la declaración de importación es para importar módulos), me gustaría que tuviera esto en cuenta. Definir convenciones en general y .module.css en específico en un archivo constante ayudaría lo suficiente para parchearlas.

De todos modos, muchas felicitaciones por los módulos CSS. Habéis hecho un trabajo magnífico, parecía una tarea "casi" imposible.

Si puedo agregar mis dos centavos en la convención de nomenclatura: tenemos una biblioteca de componentes que usa la extensión .pcss ya que necesitamos PostCSS para la compilación y decidimos usar esta convención de nomenclatura, también necesitamos importar estos CSS como módulo . ¿Cómo abordaría este caso? Actualmente estamos pirateando la configuración del paquete web y parcheando la expresión regular de prueba de los cargadores, pero se siente sucio como puede imaginar.

Me imagino que .module.css soportó postCSS tal como lo hace actualmente el .css global.

Sé lo que pasa, creo que necesito unas vacaciones.

Al revisar el PR: https://github.com/zeit/next.js/pull/9686 pensé que "vi" que los módulos CSS se importaron con un alcance tal como se importan los módulos globales.

Sinceramente pensé haber leído este código:

index.module.css

.redText {
  color: net;
}

import './index.module.css'

export default function Home () {
  return (
    <div id = "verify-red" className = "redText">
      This text should be red.
    </div>
  )
}

Evidentemente nada que ver con la realidad. En realidad, el código real es este.

import {redText} from './index.module.css'

export default function Home () {
  return (
    <div id = "verify-red" className = {redText}>
      This text should be red.
    </div>
  )
}

Solo módulos CSS como en CRA o Gatsby. De ahí la confusión, mi confusión.

Pido disculpas a todos por el error.

:-(

Cuando se utilizan módulos CSS, el principal problema es que:

Use módulos CSS en mi proyecto, y algunos componentes de terceros también usan módulos CSS.
Pero ... algunos componentes de terceros usan CSS global.

Creo que la solución de la extensión .module.css es fácil de entender e implementar.
Y los otros marcos (CRA 、 Gatsby) han llegado a un consenso.

Hasta ahora, no he tenido ningún problema con la solución de extensión.
Entonces, espero promover el desarrollo de la extensión .module.css .

Si hay otra solución sobre el problema de los módulos CSS, es mejor.

@bySabi
Aunque .m.css es más corto, pero no creo que sea mejor.
¿Es min.css o module.css ?

@ xyy94813 o exactamente lo contrario, todas las importaciones de CSS son módulos, los archivos con .global.scss serán globales

@felixmosh
Pero es hostil a los componentes publicados.

Creo que la convención es un buen valor predeterminado, pero algunas opciones de configuración específicas de los módulos CSS deberían eventualmente estar disponibles, por ejemplo, las que se pasan a css-loader , ya que algunos usuarios querrán tener control sobre cómo se "alcanzan" se emiten los nombres de las clases. Se podría agregar una opción para proporcionar una expresión regular que determina qué archivos CSS se cargan como "módulos"

ya que algunos usuarios querrán controlar cómo se generan los nombres de las clases "con alcance"

¿Ejemplos de por qué querrías eso? No puedo pensar en ninguno.

Ejemplos si ¿por qué querrías eso? No puedo pensar en ninguno.

@timneutkens Bueno, podría preferir generar un patrón de nomenclatura que se ajuste básicamente al patrón de nomenclatura de mis clases globales con solo la cadena de alcance al final.
Más allá de esto, estaba pensando en la purga posterior a la compilación o la división o carga de escenarios en los que podría querer incluir en la lista blanca un cierto espacio de nombres, pero aún no lo he resuelto.

Creo que es importante recordar que un marco obstinado está destinado a tomar decisiones por usted con el fin de eliminar la configuración inicial y hacer cumplir la uniformidad.

Algunas de esas decisiones deberían venir con valores predeterminados que se pueden cambiar a través de opciones de configuración o extensiones, pero con todo lo que personaliza, aumenta la base de código, lo que crea más código para probar, mantener y documentar, que a su vez también debe mantenerse.

Algo como el patrón de hash de salida con alcance es tan granular si llega a un punto en el que _necesita_ sobrescribir el valor predeterminado, es probable que esté en el punto en el que debería escribir el cargador personalizado que necesita usted mismo.

Cuando trabajo con nuevos desarrolladores de React, siempre me ha resultado mucho más fácil transmitir el concepto de estilos de alcance a un componente a través de className. Simplemente dé al elemento externo en su componente un className único, generalmente el mismo que el nombre de su componente, y escriba su estilo de esta manera si usa SCSS:

.Navbar {
  .logo { ... }
  .nav-item { ... }
}

Definitivamente veo los beneficios de css-modules , pero me preocupa un poco que, al dejar de admitir el método anterior, Next.js termine siendo menos amigable para los nuevos desarrolladores. Tal vez sea una buena compensación si ves que muchas personas tienen problemas con los pedidos de CSS, pero me pregunto si la aplicación de css-modules podría al menos desactivarse a través de next.config.js . O tal vez incluso podríamos tener una verificación en el tiempo de compilación que garantice que todos los estilos tengan un alcance adecuado con un className único, aunque no estamos seguros de qué tan factible es técnicamente.

Estoy un poco preocupado de que al dejar de admitir el método anterior, Next.js termine siendo menos amigable para los nuevos desarrolladores

A menos que haya entendido mal algo, no creo que lo de los módulos CSS sea exclusivo, sino que el cargador aplicaría el analizador de módulos CSS solo si el archivo que importa tiene el patrón de nomenclatura *.module.css , o *.module.scss para esa materia

@ lunelson-bl

Es semi-exclusivo a diferencia de cómo CRA o Gatsby habilitan el analizador solo cuando usa el patrón de nomenclatura Next no permitiría la importación de no módulos directamente en el componente JS.

Desde el RFC:

/* components/button.js */
import { btnLarge } from './button.module.css'

// import '../styles.css'; // <-- this would be an error

Para usar clases que no son de módulo, necesitaría importar la hoja de estilo en su hoja de estilo global que se importa solo en _app.js (si desea que se dividan y coloquen con sus archivos de componentes). De lo contrario, tendrían que colocarse directamente en esa hoja de estilo global.

Soy un nuevo usuario de next.js. Después de leer este número y me siento un poco confundido. Creo que si el next.js es compatible con build-in-css-support , por lo que no necesitamos el complemento @ next-css, pero no funciona y arroja un error sobre "ModuleParseError".
Si agrego el complemento @ next-css para agregar compatibilidad con importaciones de CSS, funciona, entonces, ¿cómo build-in-css-support sin @ next-css, puede proporcionar un ejemplo?
gracias a todos.

Soy un nuevo usuario de next.js. Después de leer este número ya estoy un poco confundido. Creo que next.js es compatible con build-css , por lo que no necesitamos el complemento @ next-css, pero no funciona y no recibe un error sobre "ModuleParseError".
Si lo agrego al complemento @ next-css para agregar soporte para la importación de CSS, funciona, entonces, ¿cómo se crea css-build sin @ next-css, puede dar un ejemplo?
gracias @ TODOS .

agregue una configuración a su next.config.js como este:

module.exports = {
  experimental: {
    css: true
  }
}

@erkanunluturk gracias, está bien, pero tiene una advertencia de función experimental, ¿importa?
¿Y cómo es compatible con antd? Sé que con-ant-design está bien.

@Timer ¿ puede proporcionar un ejemplo de compatibilidad con css de importación de diseño de hormigas [RFC]? Gracias.

Todavía tengo problemas con Router.push ("/") cuando estoy en otro enlace. ¿Alguien tiene una solución para ello? Por favor ayúdame muchas gracias

: advertencia: Deje de usar este hilo para desear el bien y el seguimiento de problemas. Este es un RFC y todavía lo están implementando.

El último comentario significativo del equipo es https://github.com/zeit/next.js/issues/8626#issuecomment -531415968 Puede evaluar la implementación actual habilitándola a través de https://github.com/zeit/next .js / issues / 8626 # issuecomment -568736218

Me estoy perdiendo la posibilidad de rastrear el trabajo. ¿Cómo podemos ayudar? @Timer ¿ es posible conectar este RFC con hitos, una hoja de ruta? ¿Qué se hace a partir de los puntos del RFC?

No tengo idea, cómo mantener el rumbo: confuso:

@StarpTech este RFC está completamente implementado; Los módulos CSS y CSS globales funcionan según la descripción de RFC.

¡Puedes probar ambos con la única bandera experimental!

Bloquearé este hilo para evitar más notificaciones. Si alguien identifica problemas, abra uno nuevo y avísenos. Publicaremos aquí cuando el soporte esté oficialmente marcado como estable (y esté activado de forma predeterminada).

Aterrizado en 9.2: https://nextjs.org/blog/next-9-2