Next.js: [RFC] Поддержка CSS

Я предполагаю, что с такими плагинами, как @zeit/next-sass уже работающими с текущей поддерживаемой разновидностью модулей CSS, .module.scss также будет работать? Или фраза «чистые модули CSS» означает только .module.css ?

Поддержка Sass для меня - это сделать или сломать для большинства проектов.

Плагины @zeit/next-css/sass/less/stylus будут устаревшими в пользу этого RFC (встроенная поддержка). Мы все еще обсуждаем, в какой степени sass будет частью ядра по сравнению с плагином. Я думаю, что когда вы добавите node-sass это включит поддержку sass. Подобно тому, что мы делаем для TypeScript. Причина, по которой мы не будем добавлять его в качестве зависимости, заключается в том, что он довольно большой и очень медленно устанавливается из-за собственных привязок и т. Д.

Это потрясающе! Как и сегодня, меня сбили с толку противоречивые имена классов css!

Вопрос, как это работает с TypeScript? Одна из причин, по которой я не включил css-модуль, заключается в том, что при импорте модуля css будет получен любой объект (может быть, немного волшебный, например, .foo-bar станет полем с именем fooBar ?), что не подходит для TS. Поскольку Next теперь является TS по умолчанию, я могу представить, что мы можем добиться большего успеха в этом вопросе?

Я не уверен, что «Автоматически исправлять известные гибкие ошибки для пользователя» будет хорошей идеей.

Я боюсь, что мы закончим запутанными сценариями, когда сторонние библиотеки компонентов на npm, которые включают таблицы стилей css, будут вести себя иначе в средах nextjs, чем в других (таких как create-react-app).

@TheHolyWaffle, исправляющий известные ошибки flexbug, создает более предсказуемое поведение - и это то же самое, что делает приложение Create React.

@zenozen Согласно спецификации модулей CSS, он не делает для вас ничего особенного в camelcase. Если вы используете имена классов с тире ( class-name ), вам нужно будет явно получить доступ к этому объекту.

например

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

// later on

Everything['class-name']

Что касается TS, мы не планируем никакой магии для обработки типов, но довольно легко определить тип TS для обработки этих файлов.

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

Что бы мы ни делали здесь, можем ли мы убедиться, что все еще легко использовать пользовательские плагины PostCSS, как сейчас, с @zeit/next-css ? Было бы очень обидно, если бы мы потеряли поддержку для этого - CRA не поддерживает это, и из-за этого невозможно использовать такие инструменты, как Tailwind CSS, каким-либо разумным способом.

В этом отношении я был бы осторожен с этими тремя функциями:

• Используйте Autoprefixer для автоматического добавления префиксов, зависящих от поставщика (без поддержки устаревших Flexbox)
• Полифил или компилируйте CSS-функции Stage 3+ с их эквивалентами.
• Автоматически исправлять известные "гибкие ошибки" для пользователя

... потому что все это делается с помощью PostCSS, и очень важно, чтобы порядок плагинов PostCSS находился под контролем конечного пользователя.

Я бы посоветовал, если вы собираетесь включить эти три плагина по умолчанию, чтобы пользователь мог полностью переопределить конфигурацию PostCSS по умолчанию, предоставив свой собственный файл postcss.config.js . Им пришлось бы добавить эти плагины вручную, если бы они пошли по этому пути, но, на мой взгляд, такой уровень контроля необходим.

TL; DR, пожалуйста, будьте осторожны, чтобы не нарушить способность пользователей полностью контролировать PostCSS, я буквально не могу использовать CRA из-за этого, и мне было бы очень грустно, если бы я больше не мог использовать Next.

Присоединившись к @adamwathan - было бы здорово получить здесь более подробную информацию о том, как будет выглядеть настройка параметров postcss. Было бы действительно здорово иметь возможность изменять конфигурацию postcss через следующий плагин, а также postcss.config.js , чтобы конфигурации, общие для нескольких проектов, можно было легко внедрить без дополнительного файла.

Я думаю, что лучше включить модули css для всего импорта css (не только для суффикса .module ), а для того, который мы хотим сделать глобальным, нам нужно будет указать суффикс .global .

Модули CSS были бы замечательными. Я думаю, что сохранение спецификации *.module.(css|scss) - это нормально, поскольку она соответствует create-react-app , позволяет вводить машинный текст и упрощает миграцию для других пользователей, плохо знакомых с Next.js

С помощью машинописного текста вы можете обеспечить типизацию модуля CSS, генерируя типизацию *.d.ts для каждого файла *.(css|scss) с помощью typed-css-modules и typed-scss-modules, но если вы не хотите этого по-прежнему требуется автозаполнение, вы можете использовать следующее расширение VS Code:
https://marketplace.visualstudio.com/items?itemName=clinyong.vscode-css-modules

@adamwathan, будьте уверены, мы

Это замечательно!! Есть ли график для этого? Это происходит в этом году?

@andreisoare, мы собираемся объединить глобальную половину этого RFC: https://github.com/zeit/next.js/pull/8710

Мы продолжим поддержку модулей CSS как можно скорее!

@adamwathan @Timer было бы замечательно, если бы мы могли продолжать использовать обычный файл postcss.config.js в корне проекта, как теперь можем с next-sass .

Так рад видеть, что это доходит до ядра.

Будет ли поддерживаться отрисовка критического пути AMP в этом RFC?

для записи, если вы можете, вы должны использовать styled-jsx, потому что он позволяет вам инкапсулировать css, html и js в одну идею, компонент. Если вы еще этого не осознали (это примечание для пользователей next.js, а не для сопровождающих), это позволяет вам не покупать весь CSS UI Kit, такой как bootstrap, вы можете попробовать 1 компонент, и если он этого не сделает не соответствует вашим потребностям, вы отбрасываете его, не взяв на себя бремя этой внешней зависимости CSS.

Я думаю, что также очень важно распространять эти знания, потому что CSS часто неправильно понимают или думают позже, и часто становятся проклятием для работы разработчиков. Но при правильной абстракции об этом довольно легко рассуждать.

и то, что «многие люди» импортируют свой CSS, не означает, что это отличная идея.

Я думаю, что одна из самых сильных сторон реакции - это то, что она инкапсулирует для вас CSS, HTML и JS. и если вы загружаете (импортируете) CSS, вы получаете своего рода побочный шаг, который дает вам выгода от реакции.

Для справки: CSS-in-CSS (или HTML) - гораздо более эффективный транспортный уровень для стилей, и совместное размещение js и стилей в одном файле не лучше, чем их совместное размещение в одном каталоге.
Более того, большинство CSS-in-JS последнего поколения извлекают CSS в CSS во время сборки для повышения производительности, поэтому правильное управление статическим CSS является обязательным. Однако - каким образом Next будет поддерживать такие извлечения, пока не разглашается.

Для справки: smile :: Использование SASS, LESS с такими фреймворками, как Bootstrap, по-прежнему актуально и отлично работает! Инкапсуляция не должна происходить на уровне JS. Альтернативой является использование БЭМ. Важно поддерживать оба пути.

@timer Работает ли

(Связано, https://github.com/zeit/next-plugins/issues/190)

Глобальный CSS не может быть разделен по пути, поэтому нет. Только модули CSS (импортированные на уровне компонентов) будут разделены по пути. 👍

Есть ли объяснение, как это влияет на проблемы № 9392 и № 9385? Просто чтобы понять, что происходит за кулисами. Так что я мог найти решение, как исправить проблемы в моей кодовой базе.

Привет. Мы стремимся обновить наше приложение React до next.js в основном, чтобы воспользоваться преимуществами отличных инструментов и рендеринга на стороне сервера.

Однако для нас очень сложно использовать модули CSS. Мы пробовали использовать следующий плагин для CSS, но это разрушило проблемы, такие как # 9392 # 9385 и другие.

Есть ли ETA для поддержки CSS-модулей (даже экспериментальной)? Есть ли способ помочь ускорить его развитие?

Значит, мы не можем импортировать CSS на уровне компонентов?

Вы можете, вам просто нужно использовать обходной путь прямо сейчас, пока проблема не будет устранена. Я думаю, вы можете найти тот, который вам подходит, в

Извините за глупый вопрос: что касается глобального CSS, чем это отличается / лучше, чем просто включение ссылки в голову?

@otw, если вы импортируете глобальный CSS, он проходит через конвейер сборки с остальной частью вашего кода, поэтому он минимизируется и т.д., а затем становится частью сборки и вывода next.js

От вас зависит, если это преимущество. Я полагаю, что большинство людей с нетерпением ждут модулей CSS, чтобы CSS, необходимый для конкретного компонента, загружался только тогда, когда компонент загружен.

Для контекста у нас есть команда разработчиков, которые использовали NextJS в течение последних двух лет для создания почти 40 веб-приложений для стартапов на ранней стадии.

Я хочу воспользоваться возможностью, чтобы обрисовать, как мы стилизуем наши приложения, чтобы показать текущие потребности, болевые точки, предупреждения о некоторых требуемых npms, с которыми мы столкнулись, и некоторую озабоченность предлагаемыми изменениями.

Текущая реализация

• Мы поддерживаем «стартовый комплект» приложения, в которое уже встроена большая часть наших основных функций. Он клонирован в качестве отправной точки, так как содержит множество расширенных функций от простого использования Bootstrap.
• Мы используем Bootstrap и Reactstrap в качестве основы нашей дизайн-системы. Поскольку нам нужна связная система проектирования, мы используем глобальный SASS с рекомендациями Bootstrap по расширению системы проектирования и включению наших собственных дополнений в формы дополнительных параметров конфигурации, миксинов, функций и т. Д. Все это реализуется посредством импорта шаблонов в файл sass. загружается глобально без модулей css через стандартный пример next-sass NextJS. Скриншот: http://prntscr.com/qc8r0g.
• Для большинства наших проектов мы можем обойтись путем стилизации в основном с помощью служебных классов, предоставляемых нашей расширенной настройкой Bootstrap, однако есть исключения. Для этих исключений мы используем плагин SASS со styled-jsx . Причина, по которой мы используем плагин SASS, заключается в том, что мы импортируем наши загрузочные переменные, функции и миксины из наших глобальных объектов, чтобы сохранить целостность системы дизайна. Мы сделали специальный импорт под названием «jsx-helper», который вводит их в наш styled-jsx. Скриншот: http://prntscr.com/qc8xbr.
• В случае некоторых компонентов макета, которым необходимо касаться тегов html, body и root div, некоторых плагинов, которые генерируют свою собственную разметку, или npms, которые используют порталы и нуждаются в CSS для касания разметки, недоступной из компонента, мы используем глобальный параметр стиля -jsx. Это последнее средство, но оно необходимо для нашего компонента макета, как вы можете видеть здесь: http://prntscr.com/qc8yo6

Текущие недостатки / проблемы

• Мы бы предпочли не использовать внедренный код SASS (проблемы с IDE и отсутствие поддержки с внедренными языками) с нашими компонентами, но пример использования внешнего файла sass с помощью styled-jsx не работает при импорте переменных начальной загрузки из-за известной ошибки компиляции с обязательными npm stylis . На данный момент проект кажется неподдерживаемым, поэтому я настоятельно рекомендую не включать его ни в одну цепочку инструментов, предлагаемую NextJS.
• Изменения в наших глобальных переменных SCSS, импортированных в SASS styled-jsx, не обнаруживаются. На самом деле существует какой-то глобальный кеш модуля npm, который мы не можем очистить, из-за которого webpack не может выполнять горячую перезагрузку изменений, которые распространяются из наших глобальных переменных Bootstrap. Выполнение полного npm ci для перестроения всей папки node_modules , очистка кеша браузера, команда консоли принудительной очистки кеша - все это не работает, поскольку здесь работает некоторый глобальный кеш npm. Поэтому нам бы очень хотелось, чтобы горячая перезагрузка работала правильно при обновлении файлов, импортированных в модули CSS / SASS, применяемые к компонентам. Короче говоря, любая обработка SASS, выполняемая компонентами, должна следить за изменениями импорта и поддерживать работающую горячую перезагрузку. Это было бы решено с помощью опции загрузчика веб-пакетов, упомянутой в предыдущем пункте.
• Нам пришлось придумать решение для разделения нашей конфигурации PostCSS в двух разных местах, поскольку глобальный SASS и styled-jsx строятся отдельно.

Опасения по поводу предлагаемых изменений

Нас слегка беспокоит идея блокировки глобальной опции с помощью компонентных модулей CSS / SASS, поскольку у нас есть некоторые варианты использования, которые в зависимости от компонента должны касаться тегов html, body и root div, а также случаев сгенерированного HTML. это не обязательно должно существовать внутри указанного компонента из-за размещения через порталы и т. д. Я думаю, что мы могли бы обойти часть этого с помощью глобального SASS и некоторой реструктуризации, чтобы мы не зависели от того, какой компонент загружен, чтобы применить конкретный глобальный CSS.

Мы хотим получить полный контроль над PostCSS и не хотели бы иметь дело с принуждением к применению определенного набора значений по умолчанию.

Извините, это был длинный ответ, но я полагаю, что у нас есть кое-какие идеи, которыми стоит поделиться. Не стесняйтесь сообщать мне, если у вас есть какие-либо вопросы, и мы с нетерпением ждем, что команды NextJS придумают дальше (каламбур)!

@Soundvessel ,

Нас слегка беспокоит идея блокировки глобального параметра с помощью компонентов CSS / SASS-модулей, поскольку у нас есть некоторые варианты использования, которые в зависимости от компонента должны касаться тегов html, body и root div, а также случаев сгенерированного HTML. это не обязательно должно существовать внутри указанного компонента

Если я вас правильно понял, вы все равно сможете добиться этого, используя :global в модулях CSS.

@ Daniellt1

Если я вас правильно понял, вы все равно сможете добиться этого, используя :global в модулях CSS.

См. Их примечание выше

Спецификатор модулей CSS разрешен в сочетании с именем локального класса

В случае нашего компонента макета мы нацелены на <html> , <body> и корневой div без имени локального класса.

В видео по этой теме также упоминалось, что они рассматривают возможность полной блокировки опции :global что для меня не имеет смысла, учитывая большое количество API-интерфейсов npms и CMS, которые генерируют разметку, которую нельзя трогать с помощью модулей css с областью видимости.

Привет, @Soundvessel - это мое видео, которое я записал для своей команды (как вы получили к нему доступ?), И оно не представляет напрямую взгляды команды nextjs и не гарантирует актуальную информацию с момента ее создания. на ранних стадиях эксперимента. Считайте RFC каноном по этой теме 😁

Я также хотел бы поблагодарить вас за предложение решения, которое позволяет использовать CSS / SASS вместо запутанного JS в решении CSS, которое требует дополнительного синтаксиса, такого как свойства camelCased и т. Д. Многие из нас приходят из более ориентированных на дизайн фон, имея многолетний опыт работы непосредственно с HTML / CSS, и это позволяет нам не переносить то, что мы видим в коде, слишком глубоко в то, что мы отлаживаем на экране.

Просто хочу добавить, если я не пропустил упомянутое выше, что автоматическое обнаружение / включение Sass - это круто, но параметры Sass API также должны быть где-то представлены: [email protected] установил хороший шаблон, включая разрешение пользователь выбирает, какой движок sass применить; их варианты могут быть приняты более 1: 1 ...

Я хотел бы предложить настраиваемое расширение для модулей CSS.
Может быть, предоставить массив для поддержки более одного расширения, кроме .module.css ?
Создание файла .module.css и его импорт import "Component.module.css" когда у вас много компонентов, некоторым разработчикам кажется нам немного раздутым.

В моем случае я хотел бы иметь возможность создать файл с расширением: .m.css , скажем Component.m.css и импортировать его как import "Component.m.css"

Если команда Next.js не сообщит о некоторых технических трудностях, которые не позволяют это сделать.

Я не думаю, что нужно открывать какую-либо конфигурацию для именования расширений, поскольку это кажется ненужным увеличением занимаемой площади, но я сомневаюсь в _need_ для расширения .module.css если это будет частью реализации:

Next.js позволит вам импортировать глобальный CSS только в пользовательские страницы / _app.js.

Сначала я думал, что .module.css потребуется для сборки, чтобы определить, что следует анализировать как модули CSS, а что не должно быть, но при импорте немодулей в любой компонент / страницу за пределами _app.js приведет к ошибке и нарушит сборку, тогда соглашение об именах не потребуется, поскольку все, что импортировано за пределы _app.js должно быть по своей природе модулем CSS.

Неужели это навязывается исключительно по условию, а не по необходимости?

Выбор соглашения module.css вступает в противоречие с конвентом, уже установленным https://github.com/css-modules/css-modules
Примеры здесь:
https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
и тут:
https://www.gatsbyjs.org/docs/css-modules/

Да, возможно, настройка расширения может усложнить задачу более чем необходимо. Но, по крайней мере, вы можете определить .module.css в постоянном файле, а не жестко закодировать в нескольких местах, чтобы изменить его с помощью исправления обезьяны

@bySabi

Разница между этой предлагаемой реализацией и create-react-app заключается в том, что импорт «обычной таблицы стилей», такой как пример, который вы связали с another-stylesheet.css вообще не разрешен. В этом случае .module.css используется для определения того, какая таблица стилей и каким образом должна обрабатываться инструментами сборки.

Спецификация CSS-модулей вообще не устанавливает соглашения об именах.

Я знаю, что CSS-модули не устанавливают никаких соглашений о расширении файлов, а о том, как модули импортируются.

Я хочу сказать, что .module.css - это соглашения, выбранные командами Next.js, и они должны «облегчить» возможность того, что некоторые пользователи могут его изменить, даже если это делается через модуль после установки, который делает monkey patching

Я думаю, что .module.css - первое соглашение об именах |

Выбор соглашения module.css противоречит конвенту, уже установленному css-modules / css-modules
Примеры здесь:
create-react-app.dev/docs/adding-a-css-modules-stylesheet
и тут:
gatsbyjs.org/docs/css-modules

Да, возможно, настройка расширения может усложнить задачу более чем необходимо. Но, по крайней мере, вы можете определить .module.css в постоянном файле, а не жестко закодировать в нескольких местах, чтобы изменить его с помощью исправления обезьяны

Здесь вы противоречите своей точке зрения, .module.css используется приложением create-react-app и gatsby для одной и той же функции. Это устоявшаяся модель.

изменение соглашения об именах, однако, не является установленным шаблоном, и нет причин разрешать это в Next.js.

Я думаю, что .module.css - первое соглашение об именах | расширение, наложенное Next.Js. Пожалуйста, поправьте меня, если я ошибаюсь.

Next.js устанавливает соглашения по параметрам конфигурации, например:

• pages каталог, являющийся маршрутами
• pages/api - маршруты API
• поддержка .js .tsx .tsx

Привет @timneutkens

Шаблон заключается в том, как CSS Modules определяет, как файлы CSS должны быть импортированы в объекты JS, имя рассматриваемого CSS является маргинальным. В связи с этим Next.js не использует этот конкретный шаблон в новой реализации.
CSS Modules как в Gatsby и CRA, уже были реализованы в Next раньше: https://github.com/zeit/next-plugins/tree/master/packages/next-css

Я не подвергаю сомнению используемое соглашение, .module.css , даже зная, что могу спутать пользователей CRA и Gatsby с CSS Modules . Подобрать подходящее имя сложно и не все всегда счастливы.

Хотя я считаю, что соглашение .m.css лучше, потому что оно короче (больше подходит для расширения) и менее избыточно (оператор импорта предназначен для импорта модулей), я хотел бы, чтобы вы приняли это во внимание. Определение соглашений в целом и .module.css в частности в постоянном файле могло бы достаточно помочь, чтобы исправить их.

В любом случае, поздравляю с модулями CSS. Вы проделали великолепную работу, это казалось «почти» невыполнимой задачей.

Если я могу добавить свои два цента на соглашение об именах: у нас есть библиотека компонентов, которая использует расширение .pcss поскольку нам нужен PostCSS для компиляции, и мы решили использовать это соглашение об именах, также нам нужно импортировать эти CSS как модуль . Как бы вы отнеслись к этому делу? В настоящее время мы взламываем конфигурацию веб-пакета и исправляем тестовое регулярное выражение загрузчиков, но, как вы можете себе представить, это выглядит грязно.

Я полагаю, что .module.css поддерживает postCSS так же, как сейчас это делает глобальный .css.

Я знаю, что происходит, думаю, мне нужен отпуск.

При просмотре PR: https://github.com/zeit/next.js/pull/9686 мне показалось, что я «увидел», что модули CSS были импортированы с ограниченными областями действия, так же как и глобальные модули.

Я искренне думал, что прочитал этот код:

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

Явно ничего общего с реальностью. На самом деле настоящий код таков.

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

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

Просто модули CSS, как в CRA или Gatsby. Отсюда путаница, мое замешательство.

Прошу прощения за ошибку.

:-(

При использовании модулей CSS основная проблема заключается в следующем:

Используйте модули CSS в моем проекте, и некоторые сторонние компоненты также используют модули CSS.
Но ... некоторые сторонние компоненты используют глобальный CSS.

Я думаю, что решение расширения .module.css легко понять и реализовать.
А другие структуры (CRA 、 Gatsby) достигли консенсуса.

До сих пор у меня не возникало проблем с расширением.
Итак, я надеюсь способствовать развитию расширения .module.css .

Если есть другое решение проблемы CSS-модулей, это лучше.

@bySabi
Хотя .m.css короче, но не думаю, что лучше.
Это min.css или module.css ?

@ xyy94813 или наоборот, весь импорт css - это модули, файлы с .global.scss будут глобальными

@felixmosh
Но это недружелюбно к опубликованным компонентам.

Я думаю, что соглашение является хорошим вариантом по умолчанию, но некоторые параметры конфигурации, специфичные для модулей CSS, в конечном итоге должны быть доступны, например, те, которые передаются в css-loader , поскольку некоторые пользователи захотят контролировать, как "ограниченная область" выводятся имена классов. Можно добавить параметр для предоставления регулярного выражения, определяющего, какие файлы CSS загружаются как «модули».

поскольку некоторые пользователи захотят контролировать, как выводятся имена классов с ограниченной областью видимости

Примеры того, зачем вам это нужно? Я не могу ни о чем думать.

Примеры, зачем вам это нужно? Я не могу ни о чем думать.

@timneutkens Что ж, я мог бы предпочесть выводить шаблон именования, который в основном соответствует шаблону именования моих глобальных классов, с только строкой с ограниченной областью в конце.
Помимо этого, я думал о сценариях очистки, разделения или загрузки после сборки, где я мог бы захотеть внести определенное пространство имен в белый список, но я еще не работал с этим

Я думаю, важно помнить, что самоуверенный фреймворк предназначен для принятия решений за вас, чтобы исключить первоначальную настройку и обеспечить единообразие.

Некоторые из этих решений должны иметь значения по умолчанию, которые можно изменить с помощью параметров конфигурации или расширений, но со всем, что вы делаете настраиваемым, вы увеличиваете кодовую базу, которая создает больше кода для тестирования, поддержки и документирования, который, в свою очередь, также необходимо поддерживать.

Что-то вроде хеш-шаблона вывода с заданной областью видимости настолько детализировано, что если вы дойдете до точки, где вам _ нужно_ перезаписать значение по умолчанию, вероятно, вы находитесь в точке, где вам нужно просто написать собственный загрузчик, который вам нужен.

При работе с новыми разработчиками React мне всегда было намного проще передать концепцию стилей области видимости компоненту через className. Просто дайте внешнему элементу в вашем компоненте уникальное имя класса, обычно такое же, как имя вашего компонента, и напишите свой стиль, подобный этому, при использовании SCSS:

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

Я определенно вижу преимущества css-modules , но меня немного беспокоит, что, если больше не будет поддерживать вышеуказанный метод, Next.js станет менее дружелюбным для новых разработчиков. Возможно, это хороший компромисс, если вы видите, что много людей сталкиваются с проблемами заказа css, но мне интересно, можно ли хотя бы отключить принудительное исполнение css-modules помощью next.config.js . Или, может быть, мы могли бы даже провести проверку во время сборки, чтобы убедиться, что все стили правильно ограничены уникальным именем класса, хотя не уверены, насколько это выполнимо технически.

Меня немного беспокоит, что, если больше не поддерживать вышеуказанный метод, Next.js станет менее дружелюбным для новых разработчиков.

Если я чего-то не понял, я не думаю, что модуль CSS является эксклюзивным, скорее загрузчик будет применять синтаксический анализатор модулей CSS, только если файл, который вы импортируете, имеет шаблон именования *.module.css или *.module.scss в этом отношении

@ lunelson-bl

Это полуисключительно в отличие от того, как CRA или Gatsby включают синтаксический анализатор только тогда, когда вы используете шаблон именования. Next запретил бы немодульный импорт непосредственно в компонент JS.

Из RFC:

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

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

Чтобы использовать немодульные классы, вам необходимо импортировать таблицу стилей в вашу глобальную таблицу стилей, которая импортируется только в _app.js (если вы хотите, чтобы они были разделены и размещены вместе с вашими файлами компонентов). В противном случае их нужно было бы поместить прямо в эту глобальную таблицу стилей.

Я новый пользователь next.js. После прочтения этого выпуска я немного запутался. Я думаю, что if the next.js поддерживает поддержку build-in-css , поэтому нам не нужен плагин @ next-css, но он не работает и выдает ошибку "ModuleParseError".
Если я добавляю плагин @ next-css для добавления поддержки импорта CSS, он работает, так как встроить поддержку css без @ next-css, можете ли вы привести пример?
Спасибо всем.

Я новый пользователь next.js. Прочитав этот выпуск, я немного запутался. Я думаю, что next.js поддерживает поддержку build-css , поэтому плагин @ next-css нам не нужен, но он не работает и не выдает ошибку «ModuleParseError».
Если я добавлю его в плагин @ next-css, чтобы добавить поддержку импорта CSS, он заработает, так как же создать css-build без @ next-css, можете ли вы привести пример?
спасибо @ALL .

добавьте конфигурацию в ваш next.config.js следующим образом:

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

@erkanunluturk, спасибо, все в порядке, но есть предупреждение об экспериментальной функции, это важно?
А как он совместим с antd? Я знаю, что дизайн с муравьями - это нормально.

@Timer, можете ли вы привести пример использования импорта ant-design [RFC] css? Благодарю.

У меня все еще проблема с Router.push ("/"), когда я нахожусь в другой ссылке. У кого-нибудь есть решение? Пожалуйста, помогите мне большое спасибо

: warning: Пожалуйста, прекратите использовать эту ветку как пожелание и средство отслеживания проблем. Это RFC, и они все еще реализуют его.

Последний значимый комментарий команды: https://github.com/zeit/next.js/issues/8626#issuecomment -531415968. Вы можете оценить текущую реализацию, включив ее через https://github.com/zeit/next. .js / issues / 8626 # issuecomment -568736218

Я упускаю возможность отслеживать работу. Как мы можем помочь? @Timer можно ли связать этот RFC с вехами, дорожной картой? Что сделано из пунктов RFC?

Понятия не имею, как не сбиться с пути: confused:

@StarpTech этот RFC полностью реализован; Глобальные модули CSS и CSS работают в соответствии с описанием RFC.

Вы можете протестировать оба с помощью одного экспериментального флага!

Я заблокирую эту ветку, чтобы предотвратить дальнейшее распространение уведомлений. Если кто-то обнаружит проблемы, откройте новый выпуск и сообщите нам! Мы опубликуем здесь, когда поддержка будет официально отмечена как стабильная (и по умолчанию включена).

Приземлился в 9.2: https://nextjs.org/blog/next-9-2