Styline содержит много плагинов для работы с пробелами и стилем кода, но это не инструмент только для проверкаи стиля. В Stylelint 54 и 101 плагина не связаны с пробелами.
Я понимаю, что у тебя более узкая задача — парсить станартный CSS 3. Но, если мы говорим про универсальный AST для CSS, то невозможно сделать парсер, после которого никогда не нужно будет ничего парсить. Например, в «CSS4» добавили «<=» токен в медиа-выражения. Полифилы — это стандартная задача для AST и тут всё равно придётся допарсивать самому.
Плюс, если мы говорим о PreCSS и других кастомных синтаксах — то там новых токенов будет ещё больше.
3. «Парсят разные части сами, как и большинство плагинов, что ненадежно… Универсальностью не пахнет, извини»
Критерий типов инструментов должен быть максимально простой и чёткий, чтобы мы не перерастали в бессмысленный терминологический спор, мешая пользователям нормально понять разницу между инструментами. Для «универсельного инструмента анализа AST» критерий должен быть близок к термину — то есть практическая возможность создать широкий класс инструментов.
Проблема в том, что можно бесконечно находить очередную функцию и обвинять другие инструменты, что они «не настоящие».
Например, парсер Rework и StyleCow не сохраняет пробелы — это очевидно мешает создать целый класс линтеров. Но у меня не подниметься язык говорить, что они не универсальный CSS инструмент.
С другой стороны, в PostCSS мы на практике поняли, что для создания линтеров очень важно иметь канал передачи сообщений от плагина к плагину. Без этого, опять же, нельзя легко создать много инструментов для линтеров (например, вывод ошибок прямо в браузер). Но точно так же, мне не придёт в голову называть все инструменты (наверянка твой будущий проект не имеет это пока) без этой фичи «не настоящими».
4. «то что он популярен и используется большим кол-вом вещей, которые дают удовлетворительный результат - факт»
Я понимаю, что у тебя другой вззгляд на AST. Но «Удовлетворительный» в отсылке ко всем инструментам — это было грубо и непрофессионально. Автопрефиксер или RTLCSS дают лучший результат в индустрии.
Я понимаю, что у тебя другой взгляд. Но нашего подхода имеются разумные причины. Клеймить его — непрофессиональное поведений.
Само собой, я согласен, что нужно парсить селекторы и значений. Но мы вынесли это в отдельные парсеры по серьёзным причинам. У PostCSS уже много плагинов, и любые изменения AST будут ломать совместимость. Поэтому, именно в рамках PostCSS, выгоднее провести эксперименты вне ядра, чтобы иметь возмоность ломать API.
У PostCSS есть идея, что AST должен иметь удобный API. И тут мы совсем не зря создали сторонние парсеры. Дело в том, что формат параметров директив и значений может быть очень любой. И даже если говорить о стандартных значениях, то там ещё интересный вопрос — как их правильно представить. Например, дерево postcss-value-parser оказалось не очень удобное.
Задача ещё сильно отягащается тем, что мы хотим узнать, что будет происходить в CSS-in-JS мире. Подключаемые парсеры для селекторов и значений, позволяют нам держать размер ядра небольшим, сохраняя возможность использовать PostCSS на клиенте без особых страданий.
Я обижаюсь не на то, что ты говоришь, что у PostCSS неудобный для минификатора парсер.
Главная проблема PostCSS сейчас — то, что все думают только о примесях и препроцессорах. Поэтому я трачу очень много времени, объясняя, что PostCSS — это универсальный инструмент для изменения/анализа CSS.
Когда ты на WSD говоришь, что «нормального инструмента для изменения/анализа CSS нет» — ты говоришь очень спорное суждение. Пример твита, с которого всё началось, показывает, что люди действительно поняли, что PostCSS не является этим типом инструмента.
Преставь себе на месте автора Sass, если бы я на конференции и в Твиттере говорил бы, что «нормального инструмента для CSS-прерпоцессинга нет».
Извини, если я тебя обидел — согласен, что они не очень хорошо подходят для описания. Я не вкладывал в эти слова эмоциональную окраску. Это не более, чем попытка сжать текст под ограничения длины Твиттера. Я использовал эти слова, только в прямом значении.
PostCSS — очевидно используется как парсер CSS и прекрасно (а не удовлетворительно) решает определённые задачи. Говорить, что такого инструмента нет — не правда, то есть ложь.
«Чёрный пиар» я использовал не в значении особознанного действия. А в том смысле, что пытаясь прорекламировать свой продукт, ты используешь неправильные способы очернения конкурементов. Говоришь, что «нормальных парсеров нет».
Мне очень нравится твой проект и у тебя был отличный доклад. Меня именно смущает твоя агрессивная и эмоциональная позиция по поводу PostCSS (это нормально критиковать наш парсер, но говорить, что мы является универсальным AST-парсером и имеем только удовлетворительнеы плагины — неправда).
Мы же отлично проводили время и я не ищу конфронтации с тобой. Меня задевает только две вещи:
- Что сейчас слушатели конфы думают, что PostCSS — это про примеси, а не универсальный AST для создания любых CSS инструментов.
- Что твоя публичная позиция непрофессиональная и приводит к невыгодной всем конкуренции. Как, например, терминологический войне за то, какие именно функции должны быть в «нормальном» инструменте.
Как невольный со-виновник драмы, чувствую потребность поучаствовать в возвращении темы в конструктивно-техническое русло.
Насколько я вчера понял по докладу, задача ставилась как раз «парсить по стандарту СSS вообще». И как раз мой первый вопрос к Роману был в том, что именно считать таким стандартом (что-то типа такого, совокупность текущих редакторских черновиков новейшего уровня, что-то другое).
Причем, насколько я понимаю, проблема-то актуальна даже для W3C, чей «официальный CSS-валидатор» тоже не в состоянии угнаться за меняющейся грамматикой языка (напр.). Так что парсер, который «официально» можно было бы считать референсным, будет необходим всем, включая разработчиков самих стандартов. Может — идея чисто в порядке мозгового штурма, простите если бредовая — есть смысл привлечь хотя бы к тестированию кого-то из рабочей группы CSS, того же Таба Аткинса?