Как добавить файл в stylelintignore

Обновлено: 03.07.2024

Папка images предназначена для хранения изображений. При сборке файлы из данной папки попадают в build/images .

src/images/sprites

Папка src/images/sprites предназначена для хранения векторных (SVG) и растровых (PNG) иконок.

src/images/sprites/png

Папка src/images/sprites/png предназначена для хранения растровых иконок. При сборке файлы из данной папки объединяются в два спрайта: build/images/sprites.jpg и build/images/sprites@2x.jpg .

src/images/sprites/svg

Папка src/images/sprites/svg предназначена для хранения векторных иконок. При сборке файлы из данной папки объединяются в один спрайт: build/images/sprites.svg .

src/js

Папка src/js предназначена для хранения скриптов.

src/js/components

Папка src/js/components предназначена для хранения скриптов отдельных компонентов, которые можно переиспользовать в любом месте проекта.

src/js/pages

Папка src/js/pages предназначена для хранения скриптов отдельной страницы, котроые не будут использоваться в других местах проекта.

src/js/vendor

Папка src/js/vendor предназначена для хранения скриптов сторонних библиотек, которых нет в репозитории npm.

src/js/main.js

Файл src/js/main.js предназначен для хранения основной логики сайта. При сборке данный файл попадает в build/js .

src/js/vendor.js

Файл src/js/vendor.js предназначен для подключения сторонних библиотек.

При сборке данный файл попадет в build/js .

src/nunjucks

Папка src/nunjucks предназначена для хранения шаблонов.

src/nunjucks/components

Папка src/js/components предназначена для хранения отдельных компонентов страниц, которые можно переиспользовать в любом месте проекта.

src/nunjucks/partials

Папка src/nunjucks/partials предназначена для хранения базовых настроек проекта.

src/nunjucks/analytics

Папка src/nunjucks/analytics предназначена для хранения настроек аналитики.

google / yandex Обратите внимание что эти файлы содержат уникальные id метрики которые можно прописать в файле data.json

src/nunjucks/partials/mixins

Папка src/nunjucks/partials/mixins предназначена для хранения Nunjucks-миксинов.

src/nunjucks/base.njk

В файле src/nunjucks/base.njk хранится базовый шаблон страниц сайта.

src/nunjucks/data.json

Файл src/nunjucks/data.json предназначен для настройки глобальных переменных для Nunjucks-шаблонов.

src/pages

Папка src/pages предназначена для хранения Html(Nunjucks) файлов страниц.

Пример, мы создали файл articles.njk и папку articles c внутренней статьеё article-1.njk внутри папки pages , на выходе мы получим следующее

src/resources

Папка src/resources предназначена для хранения различных файлов проекта. При сборке файлы из данной папки попадают в build .

src/resources/fonts

Папка src/resources/fonts предназначена для хранения шрифтов. При сборке файлы из данной папки попадают в build/fonts .

src/scss

Папка src/scss предназначена для хранения стилей.

src/scss/functions

Папка src/scss/functions предназначена для хранения SCSS-функций.

src/scss/mixins

Папка src/scss/mixins предназначена для хранения SCSS-миксин.

src/scss/vendor

Папка src/scss/vendor предназначена для хранения стилей сторонних библиотек, которых нет в репозитории npm.

Перевод гостевого поста Дэвида Кларка на CSS-Tricks.

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

Вы пишете CSS. Возможно, очень много. И вы допускаете ошибки. Возможно, тоже очень много. Миру нужен новый герой, который спасёт нас от ошибок в CSS!

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

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

Признайтесь, на самом деле никто, ни вы, ни ваши коллеги, не любите говорить о своих ошибках. Это как-то нелепо. И некоторые договорённости (например, о едином форматировании кода) определённо помогли бы делу, но, когда дело доходит до ручных исправлений, они все кажутся чересчур дотошными. Более того, они могут продемонстрировать не лучшие качества ваших коллег, когда дело дойдет до исправления мелочей.

Ко всему прочему, гораздо лучше было бы исправлять работу сразу же, чем ожидать код-ревью, на котором выяснится, что вы продублировали какое-то объявление или должны почистить отступы. Немедленная реакция поможет вам быстро усвоить договорённости по написанию кода и тратить меньше времени, раздумывая, почему CSS не работает.

Распознающий ошибки механизм — вот что нам нужно

Нам нужен надёжный, распознающий ошибки механизм, который понимает CSS и понимает наc: наши намерения, предпочтения, идеалы и слабости.

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

CSS-разработчикам нужны линтеры, как и всем остальным

Программы, предотвращающие ошибки, называются «линтерами». Для Javascript уже есть несколько хороших линтеров. В частности, ESLint просто творит чудеса, показывая всем нам, насколько хорош может быть линтер. Но в мире CSS всё было плохо — мы были ограничены несколькими вариантами: написанным на Ruby препроцессорным scss-lint и старым CSS Lint.

Но всё это было до прихода PostCSS. PostCSS, в числе прочего, помогает создавать совместимые друг с другом инструменты работы с CSS. Он может распарсить любой CSS-подобный синтаксис в Абстрактное Синтаксическое Дерево (AST, Abstract Syntax Tree — прим. переводчика), с которым в дальнейшем и работают плагины. При помощи специальных парсеров PostCSS может обрабатывать даже нестандартные, технически «невалидные» шаблоны (например, комментарии через // ).

Таким образом, созрела почва для нового мощного CSS-линтера — основанного на PostCSS и вобравшего в себя лучшие стороны scss-lint и ESLint.

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

Несколько вещей, которые можно делать с помощью stylelint

То, что написано далее — попытка подытожить возможности stylelint. Он содержит более сотни правил и огромные возможности для расширения.

Если вы уже чувствуете нарастающее нетерпение («Хорошо, хорошо, я уже поверил, что stylelint невероятен. Не надо толочь воду в ступе!»), просто пропустите этот раздел. В следующем я отвечу на часто возникающие вопросы и дам несколько подсказок.

1. Находить ошибки

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

Другие правила предназначены для отлова более сложных ошибок. Например, есть правило, которое срабатывает, когда вы использовали сокращенное написание свойства (например, margin ), перекрывающее один из его развернутых вариантов (например, margin-top ), хотя вы, скорее всего, не хотели этого. А ещё есть правило, которое срабатывает в такой ситуации: представьте, что Правило А находится до Правила Б, однако при этом перезаписывает Правило Б, поскольку селектор у Правила А более специфичен (например, Правило А объявлено в .foo.bar <. >, а Правило Б в .foo <. >). Это вам не хухры-мухры.

Ещё одно правило использует PostCSS-плагин doiuse, проверяя, будут ли ваши стили работать для всех браузеров, которые вы решили поддерживать. Другое правило использует css-colorguard, чтобы сравнивать используемые в проекте цвета, и спрашивать вас, не стоит ли использовать единый цвет вместо нескольких похожих. (Вы уже заметили, что stylelint использует одно из главных преимуществ PostCSS? Довольно просто сделать правила, использующие результаты работы других PostCSS-плагинов).

2. Навязывать лучшие практики

Если вы следуете определённой методологии при работе со стилями или имеете определённый стиль кода, должна быть возможность не принимать некоторые конструкции кода. Stylelint предоставляет вам такие возможности.

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

Вы можете запретить использование !important или браузерных хаков, не относящихся к тем браузерам, что вы поддерживаете. Если вы используете Автопрефиксер (что вы, пожалуй, должны делать), вы можете запретить использование браузерных префиксов в исходных файлах.

Если же вы хотите чего-то посерьёзнее, посвятите некоторое время настройкам, и вы сможете задавать порядок свойств в своих правилах, создавать черные и белые списки правил, значений, функций и единиц измерения.

3. Навязывать стиль написания кода

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

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

Задумка в том, что вы с коллегами можете один раз договориться о стиле кода (например, «А давайте всегда ставить пробел после двоеточия в объявлениях правил»), занести это в конфигурацию stylelint и больше об этом не вспоминать. Пусть машины страдают за вас!

4. Настраивать и расширять всё что угодно

Nicholas Zakas, создатель ESLint (и также CSS Lint), написал, что секрет успеха ESLint в его расширяемости. Stylelint следует примеру ESLint и старается быть настолько расширяемым, насколько это возможно.

Вы можете написать и опубликовать собственные правила в качестве плагинов. Уже доступно некоторое количество, и нам не терпится узнать, что ещё придумает сообщество.

Конфигурации можно расширять, и, следовательно, ими можно делиться. Мы переняли это у ESLint, как и плагины. Здесь вы можете посмотреть уже опубликованные конфигурации, и в числе прочих — конфигурации от WordPress и SUITCSS.

Если вам не нравятся встроенные в stylelint инструменты вывода, вы можете создать собственные, и даже адаптировать их для вашей организации. Также вы можете настроить оповещения, выводимые правилами.

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

И, если вам придёт в голову, как ещё можно использовать stylelint, дайте нам знать!

Ответы на часто задаваемые вопросы

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

Могу ли я использовать stylelint вместе с SCSS или Less?

Да, вы можете использовать stylelint вместе с SCSS! И совсем недавно появилась поддержка Less. Так как PostCSS позволяет использовать специальные парсеры, у stylelint нет проблем с нестандартным синтаксисом — всё, для чего можно написать PostCSS-парсер, можно прогнать через stylelint.

На данный момент существуют следующие PostCSS-парсеры — и, следовательно, поддержка stylelint — SCSS, Less, новый SugarSS. Если вы хотите поддерживать иной специальный синтаксис, помогите с написанием PostCSS-парсера к нему!

Могу ли я использовать stylelint с будущим CSS-синтаксисом?

Да! Как и в ответе выше: stylelint может разобрать всё, что понимает PostCSS, в том числе и будущий CSS-синтаксис (который вы используете, скорее всего, при помощи PostCSS-плагинов). Честно говоря, некоторые из правил stylelint как раз нацелены на будущий CSS, такие, как range и custom properties .

Конфигурация stylelint может быть огромной. С чего лучше начать?

Мы рекомендуем создать конфигурацию одним из трёх способов:

Вы можете взять уже опубликованную конфигурацию и расширить её. Мы создали и поддерживаем stylelint-config-standard, как некую основу, подходящую большинству пользователей. А ещё можно найти довольно много других конфигураций.
Начните с чистого листа и добавляйте по одному правилу. Изначально все правила выключены, поэтому, добавляя одно правило за другим, вы точно знаете, что делает каждое. Вы будете понимать каждое своё правило и уметь их настраивать.
Скопируйте стартовую конфигурацию и решите, какие опции использовать, а какие правила убрать.

Как проще всего использовать stylelint?

Самый простой способ использовать stylelint — через его CLI.

Если вы предпочитаете Gulp-плагин, для вас есть gulp-stylelint. Также есть вариант для webpack. Недавно появился плагин для Grunt (прим. переводчика, спасибо за уточнение vz2oo5). Мы надеемся, что они вдохновят людей разработать плагины и для других менеджеров задач.

Вы также можете использовать stylelint как PostCSS-плагин, включая его в любую цепочку плагинов. Иными словами, вы можете использовать stylelint везде, где можно запустить PostCSS — то есть практически в любом инструменте сборки!

Кроме того, уже существуют плагины для текстовых редакторов Atom, Sublime Text и VS Code, предоставляющие более быструю реакцию на ваш код. Всё это собрано на нашей странице Complementary Tools.

Вот как это может выглядеть в командной строке:

А вот так это выглядит в Atom:

Будет ли stylelint исправлять мои ошибки?

Кроме того, вы можете использовать и другие инструменты вместе со stylelint, например CSScomb или perfectionist (или postcss-sorting, прим. переводчика), автоматически исправляя одно и показывая другое.

Дисциплинируйте себя при помощи линтинга

Существует невероятное количество правил написания CSS. Все мы знаем, что очень просто написать плохой CSS, поэтому мы и уделяем так много времени разговорам о методологиях (SMACSS, ACSS, BEM, SUITCSS, и т.д.). Вы должны выбрать стратегию и упорно придерживаться её. Если, конечно, вы не хотите писать код, от которого будете морщиться уже через неделю.

Амбициозная цель stylelint — автоматизировать правила написания кода. Это позволит создать некий костяк правил и инфраструктуру, которые CSS-разработчики смогут внедрить в работу, чтобы улучшить свои собственные практики.

Попробуйте stylelint и расскажите нам о своих впечатлениях. Если у вас есть идеи по его улучшению — вперёд! Дополняйте наш код правилами, расширениями, тестами, багфиксами, документацией, новыми идеями или же просто обратной связью. У нас всегда найдётся работа для разработчиков любого уровня.

Опишите проблему. Это ошибка или запрос функции (новое правило, новая опция и т. Д.)?

Есть ошибка, при которой API явно не читает файлы .stylelintignore. CLI работает нормально, но не API.

С каким правилом, если таковое имеется, связана эта проблема?

Какой CSS нужен для воспроизведения этой проблемы?

Нет актуального css

Какая конфигурация stylelint необходима для воспроизведения этой проблемы?

не имеет значения

Какую версию stylelint вы используете?

Как у вас работает stylelint: CLI, плагин PostCSS, Node API?

Связана ли ваша проблема с нестандартным синтаксисом (например, SCSS, вложенность и т. Д.)?

API придерживается стиля lintignore

Что на самом деле произошло (например, какие предупреждения или ошибки вы получаете)?

Все мои файлы линтируются через API, даже если они не линтируются в CLI.

Самый полезный комментарий

Это должно оставаться открытым до тех пор, пока не будет исправлено isPathIgnored пока документация не будет изменена для отражения фактического поведения.

Все 26 Комментарий

@proProbe --ignore-path .gitignore , файл игнорирования по умолчанию имеет имя .stylelintignore (без -files )

@evilebottnawi Ой, извините, я неправильно написал .gitignore вместо .stylelintignore в заголовке. Изменил это сейчас

@shinnn Я в этом новичок. Какие из приведенных выше предложений можно использовать?

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

Любые из приведенных выше предложений, которые можно использовать

Значит, API stylelint не сломан?

Он не работает, но команда stylelint, похоже, не понимает этого из-за вашего плохого объяснения.

@shinnn Думаю, я недостаточно хорошо понимаю проблему :) Может быть, вы могли бы помочь улучшить билет, чтобы мы могли это решить? Кажется, что атомный линтер работает, так почему бы не использовать vscode?

вроде работает атомный линтер

Хорошо, здесь происходит две вещи.

@evilebottnawi кажется, что они ненамеренно верны: isPathIgnored перестал работать с файлами .stylelintignore . Похоже, что спецификации в linter-stylelint прежнему тестировали только ignoreFiles в конфигурации вместо отдельного файла .stylelintignore поэтому я не видел этого раньше.

@shinnn Похоже, что stylelint изменилось с тех пор, как я в последний раз изучал это, раньше было так, что если вы явно вызываете его для игнорируемого файла, он все равно даст вам результаты. Если я правильно помню, обработка игнорируемых файлов выполнялась только для каталогов. Кажется, что API по-прежнему работает таким образом, где, если вы вызовете lint() в фрагменте кода, он даст вам результаты, даже если он проигнорирован. Вот почему был добавлен isPathIgnored : чтобы предоставить метод проверки, будет ли путь проигнорирован, прежде чем вы запросите линт.

tl; dr:
isPathIgnored теперь не работает для файлов .stylelintignore , и можно утверждать, что lint теперь не работает для игнорируемых файлов.

@Arcanemagus, спасибо!

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

похоже, что потенциальным исправлением было бы добавить ignore.ignores(codeFileName) перед вычислением абсолютного пути.

кажется, что потенциальным исправлением было бы добавить ignore.ignores (codeFileName) перед вычислением абсолютного пути.

@billybonks Спасибо, что копали глубже! Если вы найдете время, сможете ли вы внести свой вклад в такое исправление?

конечно, я добавлю, создайте PR сегодня.

Есть какие-нибудь обновления о ходе исправления?

gulp-stylelint и плагин VSCode .stylelintignore также не работает, и я думаю, что это связано с этой проблемой.

Я изучал эту проблему, и, насколько я понял, на самом деле кажется, что API и CLI работают одинаково. Разница может заключаться только в том, как используются оба. Было бы неплохо, если бы кто-то, кто более знаком с кодовой базой, чем я, мог проверить мой анализ.

Вот код, который, как мне кажется, вызывает это:

Проблема связана с path.resolve(process.cwd(), ignoreFilePath) - если options.ignorePath не используется, тогда будет выполняться поиск .stylelintignore в текущем каталоге. Я полагаю, что большая часть использования CLI происходит из корня проекта, где хранится .stylelintignore , поэтому это может быть менее распространенной проблемой. С другой стороны, сторонние инструменты, полагающиеся на API, могут не иметь process.cwd() установленного в корень проекта, где .stylelintingore .

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

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

Я скажу, что это наименее плохой вариант. В сценариях, где это нежелательно, можно явно добавить ignorePath в файл конфигурации.

Мы также должны добавить некоторую документацию вокруг ignorePath и isPathIgnored .

Я искал с кем-то пару удаленного доступа (тусовки + телетайп), чтобы лучше познакомиться с ядром stylelint, чтобы хоть кто-то знал, как это работает. Если вы @thibaudcolas или кто-то из @ stylelint / core проявит интерес, возможно, мы сможем заняться на следующей неделе .

Я скажу, что это наименее плохой вариант.

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

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

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

Если используется options.ignorePath , то все работает независимо от того, в каком каталоге вы находитесь.

Дни меняют все в мире фрилансеров

Я полностью понимаю. Я тоже фрилансер :)

Я свяжусь с вами в сентябре на канале участников.

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

Я не понимаю, почему существуют отдельные реализации этой логики игнорирования:

isPathIgnored который проверяет ignoreFiles конфигурации с помощью minimatch и создает пустые результаты PostCSS с флагом ignored установленным в значение true.
Standalone / lint игнорирующий, который проверяет .stylelintignore и ignorePattern ( --ignore-pattern ) через ignore и отфильтровывает игнорируемые файлы. от результатов.

Структура папок и файлов

В папке src хранятся исходные файлы проекта.

Папка images предназначена для хранения изображений. При сборке файлы из данной папки попадают в build/images .

Папка src/images/sprites предназначена для хранения векторных (SVG) и растровых (PNG) иконок.

Папка src/js предназначена для хранения скриптов.

Папка src/js/vendor предназначена для хранения скриптов сторонних библиотек, которых нет в репозитории npm.

Файл src/js/main.js предназначен для хранения основной логики сайта. При сборке данный файл попадает в build/js .

Файл src/js/vendor.js предназначен для подключения сторонних библиотек.

При сборке данный файл попадет в build/js .

Папка src/pug предназначена для хранения шаблонов.

Папка src/pug/mixins предназначена для хранения Pug-миксин.

В файле src/pug/base.pug хранится базовый шаблон страниц сайта.

Файл src/pug/mixins.pug предназначен для подключения Pug-миксин из папки src/pug/mixins .

Папка src/resources/fonts предназначена для хранения шрифтов. При сборке файлы из данной папки попадают в build/fonts .

Папка src/scss предназначена для хранения стилей.

Папка src/scss/functions предназначена для хранения SCSS-функций.

Папка src/scss/mixins предназначена для хранения SCSS-миксин.

Папка src/scss/vendor предназначена для хранения стилей сторонних библиотек, которых нет в репозитории npm.

Файл src/scss/_base.scss предназначен для хранения базовых стилей.

Файл src/scss/_fonts.scss предназначен для подключения шрифтов.

Файл src/scss/_functions.scss предназначен для подключения функций из папки src/scss/functions .

Файл src/scss/_mixins.scss предназначен для подключения миксин из папки src/scss/mixins .

src/scss/_sprites.hbs — шаблон, на основе которого генерируется содержимое файла src/scss/_sprites.scss .

Файл src/scss/_sprites.scss предназначен для работы с PNG-спрайтами. Содержимое данного файла автоматически генерируется на основе шаблона src/scss/_sprites.hbs и иконок из папки src/images/sprites/png .

Файл src/scss/_variables.scss предназначен для хранения SCSS-переменных.

Файл src/scss/_vendor.scss предназначен для подключения стилей сторонних библиотек.

Файл src/scss/main.scss предназначен для хранения основных стилей сайта. При сборке данный файл преобразуется в CSS и сохраняется в build/css вместе с файлом main.css.map .

src/index.pug — шаблон главной страницы. При сборке все Pug-файлы из папки src преобразуются в HTML и сохраняются в build .

.babelrc — файл настроек JavaScript-транспайлера Babel.

.editorconfig — файл настроек редактора.

.eslintignore — файл настроек ESLint для игнорирования файлов.

.eslintrc — файл настроек ESLint.

.gitignore — файл настроек Git для игнорирования файлов.

.npmrc — файл настроек npm.

.pug-lintrc.json — файл настроек pug-lint.

.stylelintignore — файл настроек stylelint для игнорирования файлов.

.stylelintrc — файл настроек stylelint.

gulpfile.js — основной файл сборки, содержащий Gulp-задачи.

package.json — файл, содержащий базовую информацию о проекте и список требуемых библиотек.

README.md — описание проекта.

webpack.config.js — файл настроек webpack.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Веб-исследование отмечает структуру 07-stylelint и понимание правил

В прошлой статье в основном говорилось о простоте и практичности stylelint, а вот подробная статья о правилах.

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

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

конфигурация stylelint (конструкция)

Загрузить объект конфигурации

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

package.json внутри stylelint Атрибуты
одинокий .stylelintrc файл
Один stylelint.config.js Объектные файлы JS повсюду

.stylelintrc Формат файла может быть JSON или YAML. Вы также можете добавить расширение файла, чтобы указать, является ли формат содержимого файла JSON, YAML или JS. .stylelintrc.json , .stylelintrc.yaml , .stylelintrc.js 。

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

Как только одна из них будет обнаружена и разрешена, поиск прекратится, и объект будет использован.

Объект конфигурации

Объект конфигурации может иметь следующие атрибуты

rules

1. Базовый формат

Я лично считаю, что правила - это чрезвычайно важный элемент конфигурации в чекере. В stylelint более 150 правил. Эти правила не включены по умолчанию, и вам нужно устанавливать и включать их в соответствии с вашими потребностями.

Атрибут правила - это объект, его ключ - это имя правила, а значение - это конфигурация правила. Каждая конфигурация правила соответствует одному из следующих форматов:

Одно значение (основной вариант)
Массив с двумя значениями ([основной параметр, дополнительный параметр])
null (закрыть правило)

Указание основного параметра означает открытие правила.

2. Отключите правила в файле css

В файле css вы можете временно отключить определенное правило или отключить все правила:

Вы также можете отключить отдельные правила:

Если вам не нужно явно повторно включать правила, вы также можете передать /* stylelint-disable-line */ Закройте отдельные строки:

Конечно, вы также можете пройти /* stylelint-disable-next-line */ Чтобы отключить следующую строку правил, которую не нужно повторно включать явно:

Это несколько сложно, и перекрывающиеся режимы отключения и включения также поддерживают:

3. Уровень серьезности: ошибка и предупреждение.

Как и eslint, stylelint также отличается по степени серьезности. По умолчанию все правила имеют один error Степень серьезности уровня можно добавить в конфигурации defaultSeverity Атрибут для изменения значения по умолчанию

Чтобы настроить строгость каких-либо конкретных правил, используйте вспомогательные параметры. severity , Доступные значения:

В разных ситуациях будут использоваться разные уровни серьезности. Например, разные дисплеи или разные процедуры выхода и так далее.

Расширять

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

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

Например, давайте расширим stylelint-config-standard Измените отступ метки и закройте number-leading-zero правило:

Или используйте stylelint-config-standard Начните, затем положите поверх этого myExtendableConfig Слой, затем переопределите правила отступа

extends Ценность locater И в конечном итоге require() , Так что он может быть пригоден для использования node из require.resolve（） Любой формат алгоритма. Это означает locater Может быть:

в node_modules Имя модуля.
Абсолютный путь к файлу.
Относительный путь к файлу с именем .js или с расширением .json относительно эталонной конфигурации.

плагины

Плагины - это методы поддержки, наборы инструментов, нестандартные функции CSS или очень специфические правила или правила, установленные сообществом.

Если вы хотите использовать плагин, добавьте plugins Массив элементов конфигурации в файл конфигурации. Значением может быть имя модуля npm, абсолютный или относительный путь для вызова файла конфигурации.

Подключаемый модуль может предоставлять правило или набор правил. Если подключаемый модуль, который вы используете, предоставляет набор правил, вам нужно только вызвать значение конфигурации подключаемого модуля в модуле и использовать его в rules Правила предусмотрены в.

Процессоров

Процессор - это конвейер, связанный со stylelint, а измененный код передается в stylelint, и результат изменяется в соответствии с его выходом.

Процессор можно использовать только с интерфейсом командной строки и API узлов, но не с плагином PostCSS. (Плагин PostCSS игнорирует их.)

Если используется, добавьте processors Элементы конфигурации массива в файле конфигурации мало чем отличаются от раскрытия.

Если у вашего процессора есть опции, первый элемент - это «позиционирование», а второй элемент - это объект выбора.

ignoreFiles

Предоставьте массив glob или globs для игнорирования определенных файлов.

Другой способ - использовать .stylelintignore Описание файла приведено ниже.

Если глобусы являются абсолютными путями, они используются как таковые. Если они относительны, они относительны к анализу.

configBasedir
Путь к файлу конфигурации, если конфигурация является загруженным файлом, найденным stylelint
process.cwd()

Этот атрибут исключен из расширенной конфигурации: только конфигурация корневого уровня может игнорировать файлы.

defaultSeverity

Уровень серьезности по умолчанию

.stylelintignore

вы можете использовать .stylelintignore File (или укажите другой файл в режиме игнорирования), чтобы игнорировать определенные файлы. (Другой способ - использовать config.ignoreFiles, как описано выше)

над вами .stylelintignore Шаблон в файле должен совпадать .gitignore грамматика. (после того, node-ignore Проанализирует ваш шаблон). Одним из следствий этого является то, что шаблон в вашем файле всегда относительно process.cwd（） Провести анализ

Stylelint будет process.cwd（） Найдите один в .stylelintignore File, вы также можете указать путь к файлу в режиме игнорирования (абсолютный или относительно process.cwd ()) с помощью параметров --ignore path (в CLI) и ignorePath (в JS).

stylelint rules

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

Каждое правило является независимым и по умолчанию закрыто. Для правил нет значений по умолчанию.

Читайте также: