我们（前端）拥有一类工具，它们不能解决我们面临的问题，而是会影响解决问题的过程。 改变它。 此类工具的态度大相径庭-从“让我们随处推这东西，这太酷了”的精神开始疯狂，以“如果不能解决业务问题，那么我们就不需要它”这样的借口结束。 但是，无论如何，今天我们将讨论PostCSS-其中一种工具。
炒作浪潮早已过去；近年来，关于PostCSS的评论很少。 许多初学者甚至都不知道它是什么。 我认为是时候从最普通的项目中实际使用的角度来看这个工具了，在这个项目中人们解决问题，而不是玩时髦的技术。
PostCSS与SASS
哦。。。关于这个显然。 我认为现在很少有排字工人没有遇到预处理器。 SASS或我最喜欢的LESS（不太常用的Stylus）用于大型项目和小型项目。 有人试图从中榨取最多的钱，有人使用了简约集-嵌套，变量，导入。 但是，无论哪种方式，这些工具都可以解决语法问题。 它们使我们更轻松地编写代码。
大约两三年前，PostCSS就一直与预处理器进行比较。 这是可以理解的。 正式地，使用它您可以做同样的事情，做出某种比纯CSS更方便的语法。 但是所有这些都引起了沸腾的群众，主要是因为每个人在PostCSS的帮助下都做了不同的事情。 无数未知的插件，数百万个组合，除了这个或那个配置的作者之外，没有人了解它的工作原理和作用。 就像Vim或Emacs一样-您可以用它们制成一艘太空飞船，但是要教其他开发人员如何使用它将非常困难。
但是，如果我们放弃这些比较，那么PostCSS是一个工具，它使我们能够获取CSS并对其进行处理。 没有人会为了语法而使用SASS，并且在汇编之后，粘贴PostCSS并对结果做些事情。 他们彼此不矛盾。
老不代表闲着
最近，对于我们来说，创建可以完成仅想到的所有事情的联合收割机已经成为时尚，并且它们的发展永无止境。 而且，如果存储库在几个月内没有新的提交，那么所有内容-我们可以假定它已经过时并现在使用它-不必担心。 当然，我会夸大其词，但我想您自己已经注意到有时这种荒谬的想法。
在PostCSS世界中，通常一个插件可以解决一个问题。 您可以在这里看到Unix哲学的元素。 由此可以得出一个合理的结论-如果插件已经在解决其任务，则无需再执行任何操作。 您可以找到多年未更新的插件，但这并不意味着它们突然停止解决为其创建的任务。
但是，让我们开始吧……我整理了十二个插件，这些插件在实践中显示了它们能够简化版图设计师的工作并节省开发时间的能力。 但是您始终可以在评论中添加一些内容。
1号 杜伊斯
https://github.com/anandthakker/doiuse
我认为我们所有人都面临这个问题：您编写代码，签入chrome-一切正常。 您签入FF-大约。 然后在移动Safari中一切都崩溃了。 或在Edge中。 而你坐着，不明白什么是错的。 然后您凝视了很长时间的代码，喝了茶，突然间发现一种洞察力：某些浏览器不支持某些属性。 您继续前进 ，看到明显的确认。
当然，凭经验，指针本身会记住应避免的属性，但是会发生任何事情。 您无法获得充足的睡眠，可能会有紧迫的期限和紧张的情绪，需要更改的浏览器列表可能会发生变化。 然后经验将开始失败。 在这种情况下，Doiuse可以提供很大帮助。
操作原理很简单-我们向他提供了一系列浏览器和CSS。 该插件会进入caniuse数据库，并实时为我们提供不受支持的答案。
我们可以直接在package.json中设置浏览器列表。 简单方便。 PostCSS使用浏览器列表 ，如果您以前从未看过它，则它看起来像这样：
"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ]
还有一个doiuse本身的配置，如果您确定它不会影响任何属性，则可以强制其中忽略某些属性组。 例如，如果您使用多文件或由于失去某些属性的支持，则什么都不会改变：
ignore: [ 'will-change', 'object-fit' ]
插件提供的标准日志不是很可读。 它包含很多信息，并且感知起来不是很方便。 但这是可以解决的。 在相同的配置中，我们可以执行创建日志的功能。
使用console.log找出将PostCSS传递给此函数的对象如何工作。 有很多有趣的事情。
我的实践表明，最方便的选项是显示不支持的选择器和特定属性，而不指定浏览器和代码行。 如果项目使用BEM或某些类似物，并且组件代码分布在单独的文件中，则此方法可让您快速找到问题所在而无需费力。
onFeatureUsage(info) { const selector = info.usage.parent.selector; const property = `${info.usage.prop}: ${info.usage.value}`; let status = info.featureData.caniuseData.status.toUpperCase(); if (info.featureData.missing) { status = 'NOT SUPPORTED'.red; } else if (info.featureData.partial) { status = 'PARTIAL SUPPORT'.yellow; } console.log(`\n${status}:\n\n ${selector} {\n ${property};\n }\n`); }
为了不在控制台中为颜色写特殊的字符序列，可以连接颜色包，这样会更加方便。
构建时，控制台中将出现以下内容：
NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }
2号 自动前缀
https://github.com/postcss/autoprefixer
谈论他甚至令人尴尬，但我经常看到有人在2019年用双手写前缀，并向其他人保证他们确切知道哪些是不需要的。 这样的行为导致这样的事实，即代码中堆满了一堆不必要的前缀，变得完全不可读。 这影响劳动生产率。 另一方面，如果您需要恐龙的支持，则总是可以忘记某些事情。 因此，解决此问题时值得摆脱体力劳动。
自动前缀与相同的caniuse数据库一起使用，使用相同的浏览器列表，并且可以将我们指定的浏览器中真正需要的前缀添加到CSS中。 同时，代码本身变得更整洁，工作速度更快。
3号 Stylelint
https://github.com/stylelint/stylelint
当您进行大量且快速的打印时，迟早会开始犯下很多错误而没有完全注意到它们。 眼睛模糊。 在CSS的情况下，当您在浏览器中查看时，这可能会产生有趣的（实际上不是）效果-您会看到布局问题。 您看一下代码-它不存在。 您在浏览器中查看-是的。 但是在代码中-不。 结果，您可以长时间搜索一个难题，而完全不会注意到您只是想办法。 为了防止这种情况，发明了短绒。
Stylelint是一个受欢迎的选择。 他知道如何使用主要预处理器的语法，了解CSS的最新趋势，可以根据自己的喜好对其进行自定义-配置类似于eslint。 从形式上讲，无需PostCSS即可单独使用此工具，但在此不提它是错误的。
4号 Postcss-Flexbugs-修复
https://github.com/luisrudge/postcss-flexbugs-fixes
从广义上讲， postcss-fixes包括此插件。 但可以肯定的是，挠曲慢慢地取代了过去的浮法布局方法。 很好，但是我们都知道与它们相关的错误很多。 它们在flexbugs存储库中进行了描述。 其中一些需要特别注意，但也有一些非常简单，以至于它们不断从你的脑袋飞出。 例如，IE忽略了flex属性的简写形式的calc函数。 这不是经常需要的，但是如果需要的话，您的双手可以写一个简短的版本，然后您必须长时间考虑问题是什么。 幸运的是，这可以自动修复。 postcss-flexbugs-fixes插件可以解决。
在calc示例中，它将在代码中找到如下片段：
.foo { flex: 1 0 calc(1vw – 1px); }
并部署它们：
.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); }
简单方便。
5号 Postcss预设环境
https://github.com/csstools/postcss-preset-env
既然我们在谈论浏览器支持，那么谈论postcss-preset-env并不会显得不合适。 以前， cssnext扮演相同的角色。 如果您对CSS的新趋势感兴趣，那么此插件将非常有用。
从技术上讲，许多创新都可以使用旧方法来实施，但时间长，冗长且丑陋。 Preset-env帮助您以新的方式编写代码，节省时间，然后将其转换为可靠的旧版本。 当然，某些属性（如自定义属性）在旧版浏览器中根本无法实现，因此将在此处使用后备功能。
您可以从乐器的名称中猜出它类似于Babel预设的名称。 在这里，一切都是一样的-许多转换器组装成一个稳定的集合。 某些转换需要在客户端上随后连接多语言脚本，但是大多数转换完全由CSS实现。 据我了解，对于Stage2 +脚本是不需要的。 无论如何，我没有遇到他们的需要。 如果我错过了那里的东西，请纠正我。
6号 后动画
https://github.com/zhouwenbin/postcss-animation
我经常听到不同的人（大多数是CSS不太强的后端）听到他们想使用与animate.css不同的动画，但是认为连接整个库是一个坏主意。 这是很合逻辑的。 但是结果，他们花了很多时间试图自己重复这些动画。
postcss-animation插件大大加快了此过程。 我们只写动画的名称，例如：
.foo { animation-name: bounce; }
然后他从animate.css中提取实现，并将其插入代码中。
.foo { animation-name: bounce; } @keyframes bounce { from, 20%, 53%, 80%, to { animation-timing-function: cubic-bezier(0.215, 0.610, 0.355, 1.000); transform: translate3d(0,0,0); } 40%, 43% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -30px, 0); } 70% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -15px, 0); } 90% { transform: translate3d(0,-4px,0); } }
7号 列表选择器
https://github.com/davidtheclark/list-selectors
当您有多个排字机和多种样式时，就会出现代码审查的问题，有时您会目睹拥有我们所有选择器的全景图，这将是很好的选择。 知道使用了哪些ID，是否有标签选择器，或者遵循接受的方法的程度如何。 当您检查初学者的代码时，这一点尤其重要，该代码可以编写一些可以正常使用的奇怪内容，但实际上违反了公认的协议（这些协议在各个地方都固定得很好，并且有机会使这些事情自动化）。 自己滚动浏览多个样式表，以长时间检查选择器是否足够。 我们需要一种隔离它们并分别显示它们的方法。 列表选择器只是解决了这个问题。
就像doiuse一样，此插件可让您使用其功能来准备显示信息。 您可以只显示自己感兴趣的内容，也可以用不同的颜色绘制所有内容。 例如：
require('list-selectors').plugin((list) => { const inspect = require('util').inspect; console.log('SELECTORS:'.blue); console.log(inspect(list.selectors, { maxArrayLength: null }).blue); console.log('IDS:'.red); console.log(inspect(list.simpleSelectors.ids, { maxArrayLength: null }).red); })
这个例子产生了很长的选择器列表：
SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . .
8号 不可变的CSS
https://github.com/johno/immutable-css
要注意的另一件事是中断第三方库的样式。 如果我们连接了某种类型的库，然后开始从中为选择器编写我们自己的样式，那么最后，我们将得到令人困惑的代码，其中我们无法确定其来源。 这可能会导致随机的错误，这些错误然后会花费过多的时间。 尽管需要解决的问题本身可能非常简单，但我们重新定义某些事物的次数越多，最终了解所发生的事情就越困难。 在这种情况下，称为immutable-css的工具可能会派上用场。
通常，其工作原理很简单：它接收具有样式的文件，如果在选择器中找到匹配项，则会开始重新发送：
! .button was mutated 2 times [line 93, col 1]: /css/basscss.css [line 3, col 1]: /css/custom.css [immutable-css] ! .left was mutated 2 times [line 291, col 1]: /css/basscss.css [line 4, col 1]: /css/custom.css [immutable-css]
该工具的唯一问题是它不支持非CSS语法。 因此，如果在项目中使用了预处理器，则必须比较已经汇编的文件。 但是总的来说，如果任务只是确保没有人意外地从第三方库重写样式，那么这并不是那么重要。
9号 再见！
https://github.com/AoDev/css-byebye
当我们逐步向工作站点中添加一些组件时，我认为每个人都熟悉这种情况。 他们中的一些人立即投入生产，其中一些人坐了很长时间，等待轮到他们（例如，我们组成了，我们还没有完成后端工作）。 可能是假期的实验或临时解决方案。 可能有很多情况，但由于我们拥有许多组件，因此只有一个很小的部分用于战斗现场，这使它们结合在一起。 最好从当前程序集中删除所有未使用的东西。 例如，当有必要进行重新设计时，这可以显着减小其大小，并减轻将来的麻烦，而问题是，现在真正需要重写的全部内容是什么，什么不需要重写。
有不同的方法来解决此问题。 Uncss立即浮现在脑海中 。 该工具自动检测页面上使用了哪些样式，并删除了不必要的样式。 但是实际上，这几乎总是导致这样的事实，即没人知道实际使用的是什么，而不是实际使用的。 我也一直怀疑这个工具是否删除了多余的东西。 但这可能是我的偏执狂。 虽然...
再见是一个更简单的工具，我们自己输入要从CSS中删除的选择器列表。 您可以使用正则表达式。 如果您使用BEM或类似的方法，则可以使用一个简单的常规删除包含与其相关的所有内容的块。 再见！
事实证明这种方法很方便。 可以立即清除哪些样式尚未使用或已被不必要地删除，在所有源均已就绪，所有设置在一个文件中，没有任何损失的情况下，它不会造成制作多个不同装配的麻烦，而且最重要的是，解决方案简单且可预测。
10号 事后追踪
https://github.com/juanfran/postcss-trolling
以前的所有工具都可以稍微提高版图设计人员的工作效率，但是该工具仅给出了惊人的结果。 我强烈推荐它。
结论
PostCSS对版面设计人员是一个很好的帮助。 当然，如果不滥用它们。 对于许多耗时的问题，有以插件形式存在的现成的解决方案，尽管它们通常不会开发并且似乎已被放弃，但这不会影响其使用。