我们的经验从少到精

关于从普通CSS到CSS预处理器的切换已经写了很多，并且有很好的理由——预处理器增加了我们无法单独在浏览器中获得的功能和控制。从文章中赞美预处理器的优点到更专业的读物，比如Etsy的详细“大规模向SCSS过渡，“我觉得我把它们都吃了。

在爱游戏app体育官方，我们做了一些几乎没有写过的事情——从一个预处理器切换到另一个预处理器。早期，斯普劳特收养了爱游戏体育官网首页孩子少；我们在去年年底决定切换到SCSS，类似css的语法萨斯．我们花了很多时间来确保平稳的过渡，这次经历突出了Less和Sass之间的一些深层差异。

为什么?

在我们学习之前，你的第一个问题——一个合理的问题——应该是，“为什么要麻烦?”我们已经受益于变量和mixins， @imports和color函数。当然，Sass有许多Less所缺乏的特性，例如地图而且功能但我们没有他们也走了这么远。

换工作有两个主要原因:

1. 社区:搜索github lib扩展:scss，然后搜索lib扩展:less。在撰写本文时，结果很清楚:120,234个SCSS文件，29,449个Less文件。转换提供了更广泛的好想法和更大的开源池。甚至流行的Bootstrap库(Less仍然可行的原因之一)也宣布了它正在转向SCSS．
2. 速度:Libsass岩石。样式的构建时间提高了500%以上。虽然Libsass还没有赶上Sass规范的最新版本，但我们并不觉得我们遗漏了任何东西。

如何?

我们编译的CSS有近19,000个选择器。转换后，编译的CSS需要几乎相同;我们必须确保这种转变对我们的客户是不可见的。目前正在开发的功能呢?我们的最近的撰写更新更改了3837行样式——团队如何安全地在中途切换?

我们考虑了三个选择:

1. 首先将所有内容编译为CSS。这是确保我们的用户在一天内得到相同款式的唯一方法。彻底分手的想法总是很诱人，但是新代码并不总是更好的代码．即使使用工具sass-convert而且css2compass在美国，我们花在重建上的时间将远远超过任何其他选择。
2. 只在SCSS中编写新的样式。我们考虑过划清界限少是老的和坏的;时髦是新潮流．最终，我们拒绝了这个想法。立即切换将获得很多好处，没有人希望在两组mixin和变量之间保持对等。爱游戏官网皇
3. 将我们所有的Less文件转换为SCSS并修复损坏的地方。面对丢弃历史记录或添加另一个构建任务来维护的问题，我们开始转换所有内容。

清洁房子

SCSS和Less并没有什么不同，不是吗?”从Less转换到Sass，共享一系列正则表达式搜索，以改变最明显的语法差异，例如.awesome-mixin() vs @mixin awesome-mixin()。这些正则表达式搜索被卷起less2sass我们查了所有的文件。

如果真的这么简单，那就没什么可写的了。对less2sass脚本的一些拖拉请求强调了它的一些疏忽，例如字符串插值差异．更具有挑战性的是我们在转换后遇到的构建错误，这些错误突出显示了一个简单的正则表达式无法解决的差异。坦白地说，我们也发现了一些糟糕的CSS。

我们把这些构建错误列了一个清单，列出我们需要修复的地方，我们知道我们可以在转换样式之前修复大部分错误。我们决定在转换前清理我们的Less文件。

修车的混合

我们从Less和Sass处理条件的区别开始。这是一个简单的渐变混合:

Sass提供了一个简单的@if...@else结构，而我们的mixin采用了Less称之为a的结构mixin警卫．在我们的梯度mixin的例子中，我们使用它从供应商前缀的草案语法更改为W3C语法。我们知道我们必须重写这个mixin。

然后，我们停下来，花了很长时间看了我们所有的mixin。其中大多数添加了厂商前缀，解决了浏览器差异，如上面的梯度混合。输入Autoprefixer这个工具可以解析CSS，并根据支持的浏览器列表应用厂商前缀。通过向构建中添加Autoprefixer，我们消除了9个mixin。作为奖励，Autoprefixer删除了不需要的供应商前缀，这有助于我们识别CSS中的一些灰尘角落，并生成更小的编译文件。

从我们的经验中得到一个很好的教训:不要浪费时间转换或重构你可以删除的东西。

另一个值得注意的mixin差异:Less建议用分号分隔参数．只有少数是用这种方式编写的，但它们都必须在mixin定义和应用位置进行更改。幸运的是，Less同时支持分号和逗号，所以我们可以在转换步骤之前进行更改。

&滥用

在解决了mixin之后，我们将注意力转向了构建错误的另一个来源:与符号．它是Sass和Less中最强大的运算符之一，它们的工作原理非常相似。除非他们不这样做。它们的工作方式非常不同。

例如，有19,000个选择器，你可以想象我们遇到了特异性问题，通常很快就解决了:

更少产生h1。正如人们所怀疑的那样，但萨斯窒息了。我们尝试用以下方法进行修复:

跟鲁比·萨斯很搭，但写这篇文章的时候，Libsass还不支持这种用法．在这种情况下，我们甚至没有考虑改用Ruby Sass。我们把h1写出来。在.modal范围之外的modal头。我们知道这是一个问题的指示，因此通过将选择器拉出范围并用注释将其调用，我们可以更容易地在代码中识别这些问题。

当在mixin中以这种方式使用&号时，情况变得更糟。下面是我们为按钮编写的Less mixin的摘录:

同样，@at-root指令在Libsass中无法帮助我们。在这种情况下，我们必须查看特异性覆盖的根本原因并解决它。(好消息是，我们通过在其他地方删除三个过于特定的样式来解决这个问题。)

Less和Sass &号之间的另一个区别实际上是有帮助的:

我们的期望是。checkbox-wrap > .checkbox-widget， .radio-wrap > .radio-widget。然而，Less用更多的递归处理&号，并这样编译:

在任何情况下，我们都没有(或者不会)将复选框小部件用于单选按钮。幸运的是，Sass实际上解决了一个我们不知道的问题，因为我们没有查看已编译的CSS。

经验教训:经常查看编译后的CSS—否则，您不知道用户正在下载什么。

结果比较

修复和删除mixins、解决与号差异和解决其他一些不能清晰转换的位的更新发生在一个月的七次提交过程中。清理房间和确定未来的重构机会感觉很好。

然而，我们的源代码是什么样子并不重要;重要的是交付给用户的内容。我们考虑生成ast来比较我们编译的CSS。经过一些研究和实验，很明显，我们所需要的只是一种方法来知道编译后的CSS中是否发生了很少的变化。因此，好的旧式差异就足够了——差异越小越好。每个拉请求都带有Less编译前后的不同结果。Xcode开发工具FileMerge把结果放在一起比较非常方便。如果我们发现了什么意外，就会回去调查。

我们坚持使用FileMerge和diffs，一旦我们进行正则表达式查找和替换，并实际将文件转换为SCSS。然而，由于制表符和括号位置的差异，由两个不同的预处理器编译的结果使我们的差分无用。我们添加了一个额外的步骤来规范化前后CSS的格式一个简单的节点脚本．它简化了CSS，然后美化了它。再简单不过了。

规范格式帮助很大，但梳理差异仍然需要整整两天的审阅。这是一个有益的过程，但很艰巨。我们怀疑自定义AST解决方案是否有助于加快审查。所有的分歧都必须加以解决。

但差异很小。选择器的顺序略有不同，十进制四舍五入甚至颜色函数的结果略有不同。在将我们的sass -up CSS投入生产之前，我们仔细检查了每个差异。爱游戏全站下载

接下来是什么

一旦合并，正在进行的工作几乎不会停滞。由于提前完成了所有的准备工作，仍在开发中的文件更少，因此易于转换。所有人都在大约两天内开始运作。即使是重新设计的Compose团队也能在几个小时内regex到SCSS。提前计划并在按下开关之前清理现有的样式使一切变得不同。

现在，我们将继续识别模式，将大型CSS文件分解为模块，在生产中审计CSS中未使用的选择器，并在工具上花费更多时间来比较ast或其他一些已解析的CSS表示。爱游戏全站下载我提到过我们有近19,000个CSS选择器吗?我们正在研究——但那完全是另一篇文章了。