Next.js: [RFC] Suporte CSS

Eu estou supondo que com plug-ins como @zeit/next-sass já trabalhando com a versão atual suportada de módulos CSS que .module.scss também funcionaria? Ou a frase "módulos CSS puros" significa apenas .module.css ?

O suporte Sass é fazer ou quebrar para a maioria dos projetos para mim.

Os plug-ins @zeit/next-css/sass/less/stylus serão descontinuados em favor deste RFC (suporte integrado). Ainda estamos discutindo até que ponto o sass fará parte do núcleo em vez de um plugin. Meu pensamento atual é que quando você adicionar node-sass isso habilitará o suporte sass. Semelhante ao que fazemos para TypeScript. O motivo pelo qual não o adicionaremos como uma dependência é que ele é muito grande e muito lento para instalar por causa de ligações nativas etc.

Isso é emocionante! Eu fui surpreendido por nomes de classes css conflitantes assim como hoje!

Pergunta, como funciona com o TypeScript? Uma razão pela qual não habilitei o módulo css é que, importar o módulo css daria um qualquer objeto (talvez um pouco mágico, como .foo-bar se tornará um campo chamado fooBar ?), que não é compatível com o TS. Já que Next agora é TS por padrão, eu imagino que podemos fazer melhor neste assunto.

Não tenho certeza se "Corrigir automaticamente flexbugs conhecidos para o usuário" será uma boa ideia.

Temo que acabaremos em cenários confusos onde bibliotecas de componentes de terceiros no npm, que incluem folhas de estilo css, se comportarão de maneira diferente em ambientes nextjs do que em outros (como criar-reagir-app).

@TheHolyWaffle consertar

@zenozen De acordo com a especificação dos Módulos CSS, não adianta nada extravagante para você. Se você usar nomes de classe com um traço ( class-name ), você precisará acessar explicitamente isso no objeto.

por exemplo

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

// later on

Everything['class-name']

Quanto ao TS, não planejamos nenhuma mágica para lidar com os tipos, mas é muito fácil definir um tipo de TS para lidar com esses arquivos.

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

O que quer que façamos aqui, podemos garantir que ainda seja fácil usar plug-ins PostCSS personalizados como agora com @zeit/next-css ? Seria uma pena se perdêssemos o suporte para isso - o CRA não suporta isso e por isso é impossível usar ferramentas como o Tailwind CSS de qualquer forma razoável.

Eu teria cuidado com esses três recursos a esse respeito:

• Use Autoprefixer para adicionar prefixos específicos do fornecedor automaticamente (sem suporte a flexbox legado)
• Polyfill ou compilar recursos CSS do Estágio 3+ com seus equivalentes
• Corrigir automaticamente "flexbugs" conhecidos para o usuário

... porque tudo isso é feito com PostCSS, e é muito importante que a ordem do plugin PostCSS esteja sob o controle do usuário final.

Eu sugeriria que, se você for habilitar esses três plug-ins por padrão, o usuário deve ser capaz de substituir completamente a configuração PostCSS padrão fornecendo seu próprio arquivo postcss.config.js . Eles teriam que adicionar esses plug-ins manualmente se seguissem esse caminho, mas esse nível de controle é necessário na minha opinião.

TL; DR, tenha cuidado para não interromper a capacidade dos usuários de ter controle total do PostCSS. Eu literalmente não posso usar o CRA por causa disso e ficaria muito triste se não pudesse mais usar o Next.

Apoiando @adamwathan - seria ótimo obter mais detalhes aqui sobre como ficaria a personalização das opções postcss. Seria muito bom ter a opção de modificar a configuração postcss por meio do próximo plug-in, bem como postcss.config.js , de forma que as configurações compartilhadas entre vários projetos possam ser facilmente injetadas sem um arquivo extra.

Acho que é melhor habilitar os módulos css para todas as importações css (não apenas para o sufixo .module ), e aquele que desejamos ser global, precisaremos especificar um sufixo .global .

Módulos CSS seriam ótimos. Acho que manter a especificação *.module.(css|scss) é bom, pois se alinha com create-react-app , permite a digitação e migrações mais fáceis para outros usuários novos para Next.js

Com o typescript, você pode reforçar as tipificações dos módulos CSS gerando *.d.ts tipificações para cada *.(css|scss) arquivo usando typed-css-modules e typed-scss-modules, mas se você não quiser fazer isso e ainda deseja o preenchimento automático, você pode usar a seguinte extensão do VS Code:
https://marketplace.visualstudio.com/items?itemName=clinyong.vscode-css-modules

@adamwathan tenha certeza de que permitiremos a configuração PostCSS! Não temos certeza de como será a implementação _exact_ ainda, mas deve surgir naturalmente com a solicitação de pull do CSS.

Isso é ótimo!! Existe um cronograma para isso? Isso está acontecendo este ano?

@andreisoare , estamos prestes a mesclar a metade global deste RFC: https://github.com/zeit/next.js/pull/8710

Continuaremos com o suporte aos módulos CSS o mais rápido possível!

@adamwathan @Timer seria ótimo se pudéssemos continuar a usar o arquivo postcss.config.js convencional na raiz do projeto, como fazemos agora com next-sass .

Estou tão feliz em ver isso chegando ao centro.

A renderização do caminho crítico de AMP será compatível com este RFC?

para registro, se você puder, você deve usar styled-jsx porque ele permite que você encapsule css, html e js em uma ideia, um componente. Se você ainda não percebeu isso (esta é uma observação para os usuários de next.js, não para os mantenedores), isso permite que você não precise comprar um kit de interface do usuário CSS inteiro como o bootstrap, você pode tentar 1 componente e se não para atender às suas necessidades, você joga fora sem o fardo de lidar com a bagagem dessa dependência externa de CSS.

Eu acho que também é muito importante espalhar esse conhecimento porque CSS muitas vezes é mal interpretado ou considerado tardio e muitas vezes se torna a ruína do trabalho do desenvolvedor. Mas com a abstração adequada, pode ser muito fácil raciocinar sobre isso.

e só porque "muitas pessoas" estão importando seu CSS não significa que seja uma ótima ideia.

Acho que uma das coisas mais poderosas sobre o react é o fato de encapsular CSS, HTML e JS para você. e se você side-load (import) o CSS, você meio que evita o benefício que o react oferece.

Para o registro: CSS-in-CSS (ou HTML) é uma camada de transporte muito mais eficiente para estilos, e colocar js e estilos em um arquivo não é melhor do que colocá-los em um diretório.
Ainda mais - a maioria do CSS-in-JS de última geração extrai CSS para CSS no tempo de construção para fins de desempenho, portanto, o gerenciamento adequado de um CSS estático é obrigatório. No entanto - a forma como tais extrações seriam suportadas pela Next ainda não foi divulgada.

Só para constar: smile :: Usar SASS, LESS com um Framework como o Bootstrap ainda é uma coisa e funciona muito bem! O encapsulamento não deve acontecer no nível JS. Usar o BEM é uma alternativa. Apoiar as duas formas é essencial.

@timer A primeira metade disso (https://github.com/zeit/next.js/pull/8710) significa que a divisão de caminho do CSS agora funciona? Ou ainda está por vir?

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

CSS global não pode ser dividido em caminhos, portanto, não. Apenas módulos CSS (importados no nível do componente) serão divididos no caminho. 👍

Existe uma explicação de como isso afeta os problemas # 9392 e # 9385? Só para entender o que está acontecendo nos bastidores. Para isso, eu poderia criar uma solução alternativa para corrigir os problemas em minha base de código.

Oi. Estamos procurando atualizar nosso aplicativo React para next.js principalmente para aproveitar as vantagens das ótimas ferramentas e renderização do lado do servidor.

No entanto, para nós, é um requisito difícil poder usar módulos CSS. Tentamos com o próximo plug-in para CSS, mas ele destruiu o caos com problemas como # 9392 # 9385 e mais.

Existe algum ETA para suporte aos Módulos CSS (mesmo experimental)? Alguma maneira de ajudar a acelerar seu desenvolvimento?

Portanto, não podemos importar css no nível do componente?

Você pode, você só precisa usar uma solução alternativa agora até que o problema seja corrigido. Acho que você pode encontrar um que funcione para você na edição do

Desculpe pela pergunta estúpida: no que diz respeito ao CSS global, em que isso é diferente / melhor do que apenas incluir um link na cabeça?

@otw se você importar o CSS global, ele passará pelo pipeline de construção com o resto do seu código, de forma que será minimizado etc. e se tornará parte da construção e da saída de next.js

Depende de você se isso for vantagem. Eu imagino que a maioria das pessoas está ansiosa por módulos CSS para que o CSS necessário para um componente específico seja carregado apenas quando o componente for carregado.

Para contexto, temos uma equipe de desenvolvedores que tem usado o NextJS nos últimos dois anos para construir quase 40 aplicativos da web para startups em estágio inicial.

Quero aproveitar a oportunidade aqui para descrever como estilizamos nossos aplicativos para mostrar as necessidades atuais, pontos problemáticos, avisos sobre alguns npms necessários que enfrentamos e alguma preocupação com as alterações propostas.

Implementação Atual

• Mantemos um aplicativo de "kit inicial" que possui muitas das principais funcionalidades de nosso aplicativo pré-desenvolvidas. Ele é clonado como ponto de partida, pois contém muitas funcionalidades estendidas, apenas usando o Bootstrap.
• Usamos Bootstrap e Reactstrap como base de nosso sistema de design. Como queremos um sistema de design coeso, estamos usando SASS global com as diretrizes do Bootstrap para estender o sistema de design e incorporar nossas próprias adições nas formas de opções de configuração adicionais, mixins, funções, etc. Tudo isso é implementado por meio de padrões de importação em um arquivo sass carregado globalmente sem módulos css por meio do exemplo next-sass padrão do NextJS. Captura de tela: http://prntscr.com/qc8r0g.
• Para muitos de nossos projetos, podemos conseguir estilizando principalmente por meio das classes de utilitários fornecidas por nossa configuração estendida do Bootstrap, embora haja exceções. Para essas exceções, usamos o plugin SASS com styled-jsx . A razão pela qual usamos o plugin SASS é que importamos nossas variáveis ​​de bootstrap, funções e mixins de nossos globais para manter o sistema de design coeso. Fizemos uma importação especial chamada "jsx-helper" que traz isso para o nosso styled-jsx. Captura de tela: http://prntscr.com/qc8xbr.
• No caso de alguns componentes de layout que precisam tocar nas tags html, body e root div, alguns plug-ins que geram sua própria marcação ou npms que utilizam portais e precisam de CSS para tocar na marcação não acessível a partir do componente, usamos a opção global estilizada -jsx. Este é o último recurso, mas necessário para nosso componente de layout, como você pode ver aqui: http://prntscr.com/qc8yo6

Desvantagens / problemas atuais

• Preferimos não usar código SASS injetado (problemas de IDE e falta de suporte com linguagens injetadas) com nossos componentes, mas o exemplo de uso de um arquivo sass externo com styled-jsx não funciona ao importar variáveis ​​de bootstrap por causa de um bug conhecido de compilação com npm stylis . O projeto parece não ter suporte neste ponto, então eu recomendo fortemente que ele não esteja em nenhuma cadeia de ferramentas proposta pelo NextJS.
• Mudanças em nossas variáveis ​​SCSS globais importadas para nosso SASS styled-jsx não são detectadas. Na verdade, há algum tipo de cache de módulo npm global que não podemos limpar, que parece fazer com que o webpack não seja capaz de atualizar as alterações que se propagam de nossas variáveis ​​globais do Bootstrap. Fazer um npm ci completo para reconstruir a pasta node_modules inteira, limpar o cache do navegador e o comando cache clear force console não funciona porque há algum cache npm global que funciona aqui. Portanto, gostaríamos muito que o recarregamento a quente funcionasse corretamente ao atualizar os arquivos importados para os módulos CSS / SASS aplicados aos componentes. Resumindo, qualquer processamento SASS feito por componentes deve observar as mudanças nas importações e manter o recarregamento ativo. Isso teria sido resolvido pela opção do webpack loader observada no item anterior.
• Tivemos que criar uma solução para compartilhar nossa configuração PostCSS em dois lugares separados, já que o SASS global e o styled-jsx são construídos separadamente.

Preocupações com as mudanças propostas

Estamos levemente preocupados com a ideia de bloquear a opção global com módulos CSS / SASS componentes, pois temos alguns casos de uso que precisam, com base no componente, tocar nas tags html, body e root div, bem como casos de HTML gerado que não existe necessariamente dentro do referido componente devido ao posicionamento por meio de portais etc. Acho que poderíamos contornar isso com SASS global e alguma reestruturação, então não dependemos de qual componente é carregado para aplicar CSS global específico.

Queremos controle total sobre PostCSS e preferimos não ter que lidar com a obrigação de aplicar um conjunto específico de padrões.

Desculpe, esta foi uma resposta longa, mas acho que temos alguns insights que valem a pena compartilhar. Sinta-se à vontade para me avisar se tiver alguma dúvida e estamos ansiosos para ver o que as equipes do NextJS virão em seguida (trocadilho intencional)!

@Soundvessel ,

Estamos levemente preocupados com a ideia de bloquear a opção global com módulos CSS / SASS componentes, pois temos alguns casos de uso que precisam, com base no componente, tocar nas tags html, body e root div, bem como casos de HTML gerado que não existe necessariamente dentro do referido componente

Se bem entendi, você ainda deve conseguir isso usando :global em módulos CSS.

@ Daniellt1

Se bem entendi, você ainda deve conseguir isso usando :global em módulos CSS.

Veja a nota acima

O especificador de Módulos CSS é permitido quando combinado com um nome de classe local

No caso de nosso componente de layout, estamos visando <html> , <body> e div raiz sem um nome de classe local.

Também foi mencionado em um vídeo sobre este tópico que eles estão considerando bloquear a opção :global completamente, o que não faz sentido para mim, considerando o grande número de APIs npms e CMS que geram marcação que não pode ser tocada por módulos css com escopo definido.

Olá @Soundvessel - este é o meu vídeo que gravei internamente para a minha equipe (como você teve acesso a isso?), E não representa diretamente as opiniões da equipe do nextjs, nem garante informações atualizadas desde que foi feito durante os primeiros estágios experimentais. Considere o RFC como um cânone neste tópico 😁

Também gostaria de agradecer a você por propor uma solução que permite o uso de CSS / SASS em vez de uma solução JS complicada em CSS que requer sintaxe adicional, como propriedades camelCased etc. Muitos de nós vêm de uma solução mais focada em design histórico, ter anos de experiência trabalhando diretamente com HTML / CSS, e isso torna mais fácil para nós não ter que transpor o que estamos vendo no código muito profundamente para o que estamos depurando na tela.

Só quero adicionar, a menos que eu tenha esquecido alguma menção acima, que a auto-detecção / habilitação do Sass é legal, mas as opções da API do Sass precisam ser expostas em algum lugar também: [email protected] estabeleceu um bom padrão incluindo permitir o o usuário pode escolher qual motor sass aplicar; suas opções podem ser tomadas em 1: 1 ...

Gostaria de propor que a extensão para módulos CSS seja configurável.
Talvez expor uma matriz para suportar mais de uma extensão diferente de .module.css ?
Criar um arquivo .module.css e importá-lo import "Component.module.css" quando você tem muitos componentes para alguns desenvolvedores parece um pouco inchado para nós.

No meu caso, gostaria de poder criar um arquivo com a extensão: .m.css , digamos Component.m.css e importá-lo como import "Component.m.css"

A menos que a equipe do Next.js diga que há algumas dificuldades técnicas que impedem que isso seja feito.

Não acho que nenhuma configuração para extensões de nomenclatura deva ser aberta, pois isso parece um aumento desnecessário da área de cobertura, mas questiono a _necessidade_ da extensão .module.css se ela fará parte da implementação:

Next.js só permitirá que você importe CSS global dentro de páginas personalizadas / _app.js.

Inicialmente, pensei que .module.css seria necessário para a construção detectar o que deveria ser analisado como módulos CSS e o que não deveria ser, mas se importar não módulos em qualquer componente / página fora de _app.js ocorrerá um erro e interromperá a compilação, então a convenção de nomenclatura não deve ser necessária, pois qualquer coisa importada fora de _app.js deve ser um módulo CSS por natureza.

Isso está sendo forçado puramente como convenção, e não como necessidade?

A escolha da convenção module.css colide com o convento já estabelecido por https://github.com/css-modules/css-modules
Exemplos aqui:
https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
e aqui:
https://www.gatsbyjs.org/docs/css-modules/

Sim, provavelmente tornar a extensão configurável pode complicar mais do que o necessário. Mas pelo menos você poderia definir .module.css em um arquivo constante e não codificado em vários lugares para alterá-lo via monkey patching

@bySabi

A diferença entre essa implementação proposta e create-react-app é que importar uma "folha de estilo regular" como o exemplo que você vinculou a another-stylesheet.css não seria permitido de forma alguma. Nesse caso, .module.css é usado para determinar qual folha de estilo deve ser tratada de que maneira pelas ferramentas de construção.

A especificação dos Módulos CSS não estabelece nenhuma convenção de nomenclatura.

Eu sei que Módulos CSS não estabelece nenhuma convenção sobre a extensão dos arquivos, mas como os módulos são importados.

Onde eu quero chegar é que .module.css são as convenções escolhidas pelas equipes Next.js e eles devem "facilitar" a possibilidade de que alguns usuários possam alterá-la mesmo que seja por meio de um módulo de pós-instalação que faça monkey patching

Acho que .module.css é a primeira convenção de nomenclatura |

A escolha da convenção module.css colide com o convento já estabelecido por css-modules / css-modules
Exemplos aqui:
create-react-app.dev/docs/adding-a-css-modules-stylesheet
e aqui:
gatsbyjs.org/docs/css-modules

Sim, provavelmente tornar a extensão configurável pode complicar mais do que o necessário. Mas pelo menos você poderia definir .module.css em um arquivo constante e não codificado em vários lugares para alterá-lo via monkey patching

Você está contradizendo seu ponto aqui, .module.css está sendo usado por criar-reagir-app e gatsby para o mesmo recurso. É um padrão estabelecido.

alterar a convenção de nomenclatura, entretanto, não é um padrão estabelecido e não há razão para permitir isso em Next.js.

Acho que .module.css é a primeira convenção de nomenclatura | extensão imposta por Next.Js. Por favor me corrija se eu estiver errado.

Next.js estabelece convenções sobre opções de configuração, por exemplo:

• pages diretório sendo rotas
• pages/api sendo rotas de API
• suporte para .js .tsx .tsx

Olá @timneutkens

O padrão está em como CSS Modules estabelece como os arquivos CSS devem ser importados para objetos JS, o nome do CSS em questão é marginal. Nesse sentido, Next.js não está usando esse padrão específico com a nova implementação.
Os CSS Modules como em Gatsby e CRA já foram implementados em Next antes: https://github.com/zeit/next-plugins/tree/master/packages/next-css

Não questiono a convenção usada, .module.css , mesmo sabendo que poderia confundir os usuários CRA e Gatsby com CSS Modules . Escolher um nome adequado é difícil e nem todo mundo está sempre feliz.

Embora eu acredite que a convenção .m.css seja melhor porque é mais curta (mais adequada para uma extensão) e menos redundante (instrução de importação é para importar módulos), gostaria que você levasse isso em consideração. Definir convenções em geral e .module.css específicas em um arquivo constante ajudaria o suficiente para corrigi-los.

Enfim, muitos parabéns pelos módulos CSS. Você fez um trabalho magnífico, parecia uma tarefa "quase" impossível.

Se eu puder adicionar meus dois centavos na convenção de nomenclatura: temos uma biblioteca de componentes que usa a extensão .pcss pois precisamos PostCSS para compilação e decidimos usar essa convenção de nomenclatura, também precisamos importar esses CSS como módulo . Como você abordaria este caso? No momento, estamos hackeando a configuração do webpack e corrigindo o regex de teste dos carregadores, mas parece sujo, como você pode imaginar.

Eu imagino que .module.css suportava postCSS exatamente como .css globais fazem atualmente.

Eu sei o que acontece, acho que preciso de férias.

Ao revisar o PR: https://github.com/zeit/next.js/pull/9686 , pensei ter "visto" que os módulos CSS foram importados com escopo assim como os módulos globais são importados.

Sinceramente pensei ter lido 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>
  )
}

Obviamente, nada a ver com a realidade. Na realidade, o código real é este.

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

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

Apenas Módulos CSS como CRA ou Gatsby. Daí a confusão, minha confusão.

Peço desculpas a todos pelo erro.

:-(

Ao usar Módulos CSS, o principal problema é que:

Use Módulos CSS no meu projeto, e alguns componentes de terceiros também usam Módulos CSS.
Mas ... alguns componentes de terceiros usam CSS global.

Acho que a solução da extensão .module.css é fácil de entender e implementar.
E os outros frameworks (CRA 、 Gatsby) chegaram a um consenso.

Até agora, não encontrei nenhum problema com a solução de extensão.
Assim, espero promover o desenvolvimento da extensão .module.css .

Se houver outra solução para o problema dos módulos CSS, é melhor.

@bySabi
Embora .m.css seja mais curto, mas eu não acho que seja melhor.
É min.css ou module.css ?

@ xyy94813 ou o oposto exato, todas as importações de css são módulos, os arquivos com .global.scss serão globais

@felixmosh
Mas, é hostil para componentes publicados.

Acho que a convenção é um bom padrão, mas que algumas opções de configuração específicas para módulos CSS devem eventualmente ser disponibilizadas, por exemplo, aquelas que são passadas para css-loader , já que alguns usuários vão querer controlar como o "escopo" nomes de classes são produzidos. Uma opção pode ser adicionada para fornecer um regex que determina quais arquivos CSS são carregados como "módulos"

já que alguns usuários vão querer controlar como os nomes das classes "com escopo" são produzidos

Exemplos de por que você quer isso? Não consigo pensar em nenhum.

Exemplos se por que você quer isso? Não consigo pensar em nenhum.

@timneutkens Bem, talvez eu prefira
Além disso, eu estava pensando em purgar ou dividir ou carregar cenários pós-compilação em que talvez queira colocar um determinado namespace na lista de permissões, mas ainda não resolvi isso

Acho importante lembrar que uma estrutura opinativa serve para tomar decisões por você a fim de eliminar a configuração inicial e impor uniformidade.

Algumas dessas decisões devem vir com padrões que podem ser alterados por meio de opções de configuração ou extensões, mas com tudo que você torna personalizável, você aumenta a base de código que cria mais código para testar, manter e documentar que, por sua vez, também precisa ser mantido.

Algo como o padrão de hash de saída com escopo é tão granular se você chegar a um ponto em que _precisa_ sobrescrever o padrão, é provável que você esteja no ponto em que deveria apenas escrever o carregador personalizado de que precisa.

Ao trabalhar com novos desenvolvedores do React, sempre achei muito mais fácil transmitir o conceito de estilos de escopo para um componente via className. Basta dar ao elemento externo em seu componente um className exclusivo, geralmente igual ao nome do seu componente, e escrever seu estilo desta forma, se estiver usando SCSS:

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

Eu definitivamente vejo os benefícios de css-modules , mas estou um pouco preocupado que, por não suportar mais o método Next.js acima, acabe se tornando menos amigável para novos desenvolvedores. Talvez seja uma boa troca se você estiver vendo muitas pessoas enfrentando problemas de pedidos de CSS, mas eu me pergunto se a aplicação de css-modules poderia pelo menos ser desabilitada via next.config.js . Ou talvez pudéssemos até ter uma verificação de tempo de construção que garanta que todos os estilos tenham o escopo apropriado com um className exclusivo, embora não tenhamos certeza de como isso é tecnicamente factível.

Estou um pouco preocupado com o fato de que, por não suportar mais o método anterior Next.js, acabe se tornando menos amigável para novos desenvolvedores

A menos que eu tenha entendido algo errado, não acho que a coisa dos Módulos CSS seja exclusiva, em vez disso, o carregador aplicaria o analisador dos Módulos CSS apenas se o arquivo que você importar tiver o padrão de nomenclatura *.module.css ou *.module.scss para esse assunto

@ lunelson-bl

É semi-exclusivo, ao contrário de como CRA ou Gatsby habilitam o analisador apenas quando você usa o padrão de nomenclatura. Next não permite a importação de não-módulo diretamente para o componente JS.

Do RFC:

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

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

Para usar classes não modulares, você precisa importar a folha de estilo para sua folha de estilo global, que é importada apenas para _app.js (se você quiser dividi-los e colocá-los em conjunto com seus arquivos de componente). Caso contrário, eles precisam ser colocados diretamente na folha de estilo global.

Sou um novo usuário de next.js. Depois de ler esta edição e me sentir um pouco confuso. Eu acho que se o next.js suporta suporte a css embutido, então não precisamos do plugin @ next-css, mas ele não funciona e gera um erro sobre "ModuleParseError".
Se eu adicionar o plug-in @ next-css para adicionar suporte a importações CSS, ele funcionará, então, como build-in-css-support sem @ next-css, você pode fornecer um exemplo?
obrigado @todos.

Sou um novo usuário de next.js. Depois de ler esta edição e estou um pouco confuso. Eu acho que next.js oferece suporte a build-css , então não precisamos do plugin @ next-css, mas ele não funciona e não obtém um erro sobre "ModuleParseError".
Se eu adicioná-lo ao plugin @ next-css para adicionar suporte à importação CSS, ele funcionará, então como você cria css-build sem @ next-css, você pode dar um exemplo?
obrigado @ALL .

adicione uma configuração ao seu next.config.js como este:

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

@erkanunluturk obrigado, está tudo bem, mas tem um aviso de recurso experimental, isso importa?
E como é compatível com o Antd? Eu sei que o with-ant-design está bem.

@Timer você pode fornecer um exemplo de importação ant-design use [RFC] suporte a css? obrigado.

Ainda tenho problemas com Router.push ("/") quando estou em outro link. Alguém tem solução para isso? Por favor me ajude muito obrigado

: aviso: Por favor, pare de usar este tópico como bom desejo e rastreador de problemas. Este é um RFC e eles ainda estão implementando.

O último comentário significativo da equipe é https://github.com/zeit/next.js/issues/8626#issuecomment -531415968 Você pode avaliar a implementação atual ativando-a em https://github.com/zeit/next .js / issues / 8626 # issuecomment -568736218

Estou perdendo a possibilidade de rastrear o trabalho. Como podemos ajudar? @Timer é possível conectar este RFC com marcos, um roteiro? O que é feito a partir dos pontos da RFC?

Não faço ideia, como se manter na linha: confused:

@StarpTech este RFC está completamente implementado; Os módulos CSS e CSS globais estão funcionando de acordo com a descrição RFC.

Você pode testar ambos com o único sinalizador experimental!

Vou bloquear este tópico para evitar mais propagação de notificações. Se alguém identificar problemas, abra um novo problema e nos informe! Publicaremos aqui quando o suporte for oficialmente marcado como estável (e ativado por padrão).

Chegou em 9.2: https://nextjs.org/blog/next-9-2