Комментарии 14
UI developer. Верстаю неверстаемое
Наверстай упущеное.
Спасибо. Есть кое-что интересное.
Ребят, давайте откровенно, сам постцсс — это для довольно специфических ситуаций полезен. В остальных случаях, это больше дань моде, т.к. «старые» инструменты работают не хуже и нет смысла переходить со старого стека на постцсс. Новичкам подобные помощники только помешают научиться нормально верстать из-за исправления ошибок, а профи и без этого знают что и как. Да, линтеры, автопрефиксер очень важны и нужны, но вот польза остальных плагинов(кроме последнего) не так очевидна.
Пожалуйста, прежде чем добавлять к себе Postcss-preset-env прочитайте что именно он за собой тянет. Вашему проекту совсем не обязательно нужно применять столько трансформаций при каждой сборке. Вполне возможно что будет достаточно взять 1-2 плагина из этой сборки и подключить их отдельно. Это будет так же наглядно отражать какие конкретно зависимости есть в вашем проекте, вместо одной зависимости на всё.
Если на проектах каждый добавляет что-то от себя вы в любом случае придёте к ситуации когда объём зависимостей будет выглядеть как зоопарк. Только на одной чаше весов у вас контролируемый и чёткий список зависимостей, а на другой чёрная коробка, в которой может быть что угодно. По-моему между очевидным и неочевидным выбора не стоит. Я не очень понимаю аргумент с «каждый раз вникать», ведь чтобы работать с post-css-env вам нужно сначала вникнуть во все плагины которые там есть, что по мыслительной нагрузке будет всегда больше чем разбираться в отдельных плагинах.
Представьте что человек написал код на stage 0 и ни кому об этом не сказал (а код-ревью вёрстки это скорее исключение чем правило), вы это никак не проконтролируете с таким плагином и люди будут так писать потому что это просто. Всё-таки когда вам нужно приложить некоторые усилия чтобы писать на stage 0 это очень мотивирует несколько раз подумать а нужно ли оно вообще и можно ли решить эту проблему как-то иначе. Если мы говорим про хорошие практики то все они строятся именно на том чтобы максимально уменьшить возможность сделать плохо для проекта\команды. И в данном случае post-css-env является очень плохой практикой, которая по факту развязывает руки для давнокода.
Так же стоит отметить что post-css-env всего лишь агрегатор плагинов. Если у вас поломался какой-то из этих плагинов вам придётся ждать когда фикс добавят в post-css-env (или форкать и фиксить самому), вместо того чтобы обновить плагин отдельно.
Я не очень понимаю аргумент с «каждый раз вникать», ведь чтобы работать с post-css-env вам нужно сначала вникнуть во все плагины которые там есть, что по мыслительной нагрузке будет всегда больше чем разбираться в отдельных плагинах.
Один раз вникнув в современный синтаксис, потом везде его используешь. А если наборы разные, то очень велика вероятность прийти, написать что-то и только потом при тестировании в разных браузерах обнаружить, что какой-то трансформации нет и все сломалось. Это как ES6 и Babel — научился использовать новый синтаксис и используешь его везде, не задумываясь, что какая-то его часть может внезапно отсутствовать. Вы же не скажете, что там тоже нужно все трансформации по одной собирать?
Если у вас поломался какой-то из этих плагинов вам придётся ждать когда фикс добавят в post-css-env (или форкать и фиксить самому), вместо того чтобы обновить плагин отдельно.
Эти плагины решают конкретные задачи, их нет смысла постоянно обновлять.
То что у Babel есть preset-env совершенно не означает что он делает тоже самое что postcss-preset-env. Как раз в бабеле полифилятся полностью готовые спецификации, см. https://new.babeljs.io/docs/en/next/babel-preset-env.html
Это похоже скорее на autoprefixer, чем на preset-env.
И бабель уже проходил путь preset-stage-0, что-то похожее на то что в PostCSS, только в postcss-preset-env ситуация ещё хуже потому что смешались все стейджи: 0, 1, 2, 3. И вот к чему это привело у бабеля: https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets
А если наборы разные, то очень велика вероятность прийти, написать что-то и только потом при тестировании в разных браузерах обнаружить, что какой-то трансформации нет и все сломалось.
А каким образом postcss-preset-env решает эту проблему? Какая разница как подключен плагин который не полифилится в конкретном браузере? Вы и в сборке и по отдельности получите эту проблему.
Эти плагины решают конкретные задачи, их нет смысла постоянно обновлять.
Здесь нет логической связи, если плагин работает некорректно его нужно починить, а наличие этих плагинов в одном пакете усложняет этот процесс. Допустим нужно откатиться на старую версию плагина которая работала корректно, при этом остальные плагины должны быть на последней версии потому что там добавились какие-то фишки или фиксы, и это превращается в очень нетривиальную задачу.
А если наборы разные, то очень велика вероятность прийти, написать что-то и только потом при тестировании в разных браузерах обнаружить, что какой-то трансформации нет и все сломалось.А каким образом postcss-preset-env решает эту проблему?
Мы будто о разных вещах говорим. Допустим я использую all в одном проекте. Привык, что эта штука есть. Перехожу в другой проект, по привычке ее использую, даже не думая, что ее может не быть, но потом тестировщик говорит, что в IE все сломалось. А почему? Потому что в местном конфиге эту трансформацию не включили. А если проектов 10? 20? В одних эта трансформация уже есть, а в других — еще нет. Не проверять же каждый раз перед работой список зависимостей. Postcss-preset-env дает один и тот же набор. Не будет такого, что что-то есть, есть, а потом раз — и нету.
если плагин работает некорректно его нужно починить… там добавились какие-то фишки
Работал, работал и вдруг сломался? Не припомню за последний год такого. И опять возвращаемся к тому, что новая функциональность в них не добавляется. Каждый решает только одну задачу и они обычно годами не обновляются.
10 PostCSS плагинов, которые сэкономят время вашему верстальщику