Estou tendo exatamente o mesmo problema: https://github.com/zeit/next.js/issues/11946#issuecomment -615298112

O mesmo problema aqui também: choro:
Descrevi meu problema aqui: https://github.com/zeit/next.js/pull/11901#issuecomment -614644961

Algum progresso? Ainda tenho o mesmo problema e não consigo colocá-lo em produção.
Testado em 9.3.7-canary.9

@EduardoPedrosa
Status: v9.3.7-canary.11 e o problema ainda persiste.

Parece que estamos tendo um problema semelhante com componentes de uma biblioteca de componentes compartilhados em nosso monorepo - quaisquer estilos em nosso aplicativo que afetam esses componentes são substituídos pelos estilos de biblioteca, apesar do fato de que a especificidade dos estilos em nossos arquivos CSS de aplicativo é superior e, portanto, deve ter precedência. Parece bom no modo dev, mas não em produção :(

(Estamos usando módulos SCSS com @zeit/next-sass )

Quando eu estava usando @ zeit / next-sass ou @ zeit / next-css tudo estava muito bem com a ordem, preferência e duplicatas entre os chuncks. :pensando:

O verdadeiro problema para mim começa quando atualizei nextjs para 9.3 e comecei a usar módulos css.

Tentei os dois métodos (next-sass e embutido) - o problema existia em ambos os casos

Minha pilha:
1) Módulos CSS
2) SCSS
3) Dart-Sass com importações @use

Experimentei muitas variações e esta funciona para mim (sem duplicatas de estilos):

1) package.json:

"@zeit/next-css": "^1.0.1",
"@zeit/next-sass": "^1.0.1",
"next": "9.2.1", (9.4.1 is current)
"node-sass": "npm:[email protected]", (this is dart sass, but can be used default)

2) next.config.js

const path = require('path')
const withSass = require('@zeit/next-sass')
const withCSS = require('@zeit/next-css')
const withBundleAnalyzer = require('@next/bundle-analyzer')({ // Optional, of course
  enabled: process.env.ANALYZE === 'true',
})

module.exports = withBundleAnalyzer(
  withCSS(
    withSass({
      cssModules: true,
      sassLoaderOptions: {
        // Resolving SASS absolute imports
        includePaths: [path.resolve(__dirname, 'src')],
      },
      cssLoaderOptions: {
        importLoaders: 2,
        localIdentName:
          process.env.NODE_ENV === 'production'
            ? '[hash:base64]'
            : '[name]__[local]__[hash:base64:5]',
      },
      webpack(config, options) {
        // Resolving absolute imports
        config.resolve.modules.push(path.join(__dirname, 'src'))

        // Make global styles work
        config.module.rules.forEach(rule => {
          if (rule.test && rule.test.toString().includes('.scss')) {
            rule.rules = rule.use.map(useRule => {
              if (typeof useRule === 'string') {
                return {
                  loader: useRule,
                }
              }

              if (useRule.loader.startsWith('css-loader')) {
                return {
                  oneOf: [
                    {
                      test: new RegExp('.module.scss$'),
                      loader: useRule.loader,
                      options: useRule.options,
                    },
                    {
                      loader: useRule.loader,
                      options: {},
                    },
                  ],
                }
              }
              return useRule
            })
            delete rule.use
          }
        })

        return config
      },
    }),
  ),
)

3) Importar estilos globais (não módulos) como este:

index.scss:

...
<strong i="19">@import</strong> '~emoji-mart/css/emoji-mart.css';
...

Será ótimo se alguém tentar essa configuração, para que eu possa ter certeza de que realmente funciona.

Eu sugiro substituir este:

.other-page__component-override { background: pink; }

Com isso:

.other-page .component-override { background: pink; }

Portanto, os estilos específicos da página só se aplicam a essa página específica =).

Também estou tendo problemas com esse bug.
Mudei o próximo css para css embutido e aconteceu.
Ele funciona no modo de desenvolvimento, mas não funciona no modo de produção quando o CSR é usado. No SSR, não há problema.

Eu uso o próximo 9.4.4 com suporte a css embutido e também tenho esse problema, que acontece na produção.

O mesmo problema no próximo 9.4.4. Apenas em modo de produção

Isso acontece com nosso ambiente de produção no próximo 9.4.4 e, de alguma forma, encontramos uma solução.

Ao usar node-sass , tentamos várias opções do documento e resolvemos isso adicionando um novo sassOptions a next.config.js

module.exports = {
  ...,
  sassOptions: {
    outputStyle: 'expanded',
  },
}

Referência: outputStyle

Após verificar o nome da classe css após next build , isso parece estar funcionando.
Espero que isto ajude!

Obrigado por compartilhar @ Howard86 , tentei, mas não funcionou aqui. Estamos usando next-css e next-sass em nossas compilações também (não o suporte CSS embutido de next, e tendo o mesmo problema descrito neste problema), e a duplicação ocorre em classes provenientes de puro css importado como css- módulos, que não vêm de estilos sass

@ Howard86 @ alexandre-marchina

Estou usando o CSS integrado do próximo capítulo 9.4.4 e sua solução também não funcionou para mim. :choro:

Eu tenho o mesmo problema com o antd e o próximo 😞

o mesmo problema . css carrega perfeito no dev, mas no produto alguns pedaços de css não carregam

O mesmo problema aqui também.

Experimentou os mesmos problemas com a próxima v9.5.1 na construção do produto, na construção do dev os estilos estão ok.

Este bug torna o uso de módulos css em next.js impossível (porque ninguém quer adicionar! Importante em estilos)

Este bug torna o uso de módulos css em next.js impossível (porque ninguém quer adicionar! Importante em estilos)

Você pode aumentar a especificidade dos estilos que substituem os estilos básicos. Por exemplo, vamos ter a dependência de componentes como Button <- IconButton <- MoreSpecificButton. Nesse caso, Button tem seus próprios estilos que são recarregados ao alternar para outra página e, portanto, substitui os estilos de IconButton e MoreSpecificButton. Se IconButton tiver seus estilos definidos como .className.className , e MoreSpecificButton também tiver seus estilos como .className.className , Button não os substituirá. E tendo o fato de que a ordem dos estilos IconButton e MoreSpecificButton está correta em css, os estilos de MoreSpecificButton sempre substituirão o IconButton - esperado.

Experimentou os mesmos problemas com a próxima v9.5.1 na construção do produto, na construção do dev os estilos estão ok.

Eu estou experimentando o mesmo problema.

+1 com Tailwind, Bootstrap. A solução alternativa atual é importar todos os estilos por meio do link rel no _document.js. Para o Tailwind, é uma versão css personalizada. Esse problema é muito chato.

Estou usando módulos css com tailwind (importação css global normal). CSS inlining resolveu a ordem de carregamento, mas não sei se ainda está duplicando, é apenas uma solução alternativa. Na produção, não notei um estilo substituindo o outro.

https://github.com/vercel/next-plugins/issues/238#issuecomment -432211871

Isso foi corrigido no canário Next.js mais recente. Atualize para next@^9.5.3-canary.7 e nos informe!

Não resolve isso para mim, por exemplo, alturas de linha, espessuras de fonte, cores de fundo, bordas são diferentes em dev e prod.

@talaikis, por favor, abra uma nova edição com uma demonstração totalmente reproduzível então! Eu testei o código exato dado nesta reprodução e está funcionando em canary agora.

Conserte para mim, mas causa outro problema mais crítico.
No meu caso, quando eu mudo apenas o url hash usando Router.push( localhost: 3000 / # change ) coming from localhost: 3000 `todas as folhas de estilo recarregam novamente causando a tela piscando.

Você pode tentar 9.5.3-canary.9 ?

@Timer executando npm i :

Tentei 9.5.3-canary.9 mas ainda persiste o problema com o hash.

Eu não mencionei isso, mas estou usando 9.5.2 e quando migrei para 9.5.3-canary.6 também há um erro no console do devtools quando uso o roteador para alterar o hash como acima.
O problema não existe em 9.5.3-canary.5 .

@fabinppk por favor abra um novo exemplar com uma reprodução!

Só queria confirmar que o problema original parece ter sido corrigido em 9.5.3-canary.9 . Obrigado @Timer

Obrigado por confirmar @petewarman!

@Timer certeza. Eu acho que sua correção está ok e não está relacionado com esse problema no devtools.
Obrigado. : +1:

Pode confirmar que isso ainda está acontecendo com 9.5.6-canary.11 , as classes são duplicadas entre os blocos.

@glottonous todos os problemas comentados nesta

Ps: estou usando 9.5.5. 👌👌

@fabinppk Posso confirmar que o mesmo problema ainda está acontecendo desde 9.5.6-canary.11 .

@glottonous Fiz alguns testes no meu projeto com a versão 9.5.6-canary.11 e não tive problemas.

Se você realmente estiver tendo um problema, abra um novo problema fazendo referência a este. : +1:

no nextjs 10, mesmos problemas

Mesmos problemas 10.0.1

Comecei # 19055 com uma demonstração reproduzível.