背景

可能看到这个题目，你会觉得scss编译出错还用检测吗？
的确，scss出错的时候（比如@import路径出错），编译器会自动帮你检测，只要你注视着命令行，或者提交的时候检查一下，就没什么问题。

不过在我们组里，还是遇到过线上的scss编译出错问题，就像这样：

scss编译出错

可能是某个程序员没有注视命令行，也没有在提交的时候人工检查一下，最后出了问题...

再加上，我们这边有个组件池，里面几十个组件repo，维护的人超过20个，大大提高了犯错的概率。所以急需工具解决这个问题。

分析

这里涉及到两个问题：

在什么阶段去检测
如何检测

比如在提交之前，去重新编译一遍scss，如果报错则不提交，否则提交。这里的在提交之前即是阶段，后面的则是检测手法。

在什么阶段去检测

我最先想到的是git hooks，这种方式需要在每个工程的.git文件里加上相应的hook，可以在pre-commit阶段，也就是提交之前进行检测。但是由于有几十个repo，个个都要加上很是麻烦。

或者加在gitlab-ci里，在push到远程仓库（挂在gitlab上的）时会触发CI，如果出错会收到报警邮件。不过，这同样存在上述的问题。

还有一种就是在部署的时候做检测。由于部署的时候会把引用到的组件repo全部拉下来，所以可以在这个阶段针对每个repo都做一下检测，如此只用改一下部署脚本。

如何检测

最简单的是直接用scss命令行重新编译一下。

另一种就是检测css里面有没有报错。下面是一段编译出错产生的css的报错信息：

/*
Error: Invalid CSS after "...    width: 100%": expected "{", was ";"
        on line 26 of src/slideModal/wap/component.scss

21:         @include transition(0.25s opacity ease-out);
22:     }
23: 
24:     .container{
25:         position: fixed;sdf
26:         width: 100%;
27:         bottom: rem(-800);
28:         height: rem(800);
29:         background: white;
30:         @include transition(0.25s bottom ease-out);
31:     }

Backtrace:
src/slideModal/wap/component.scss:26
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:1189:in `expected'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:1125:in `expected'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:1120:in `tok!'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:656:in `block'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:726:in `declaration_or_ruleset'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:676:in `block_child'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:668:in `block_contents'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:657:in `block'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:726:in `declaration_or_ruleset'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:676:in `block_child'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:668:in `block_contents'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:657:in `block'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:649:in `ruleset'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:675:in `block_child'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:668:in `block_contents'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:125:in `stylesheet'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/scss/parser.rb:41:in `parse'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/engine.rb:406:in `_to_tree'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/engine.rb:381:in `_render_with_sourcemap'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/engine.rb:298:in `render_with_sourcemap'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/plugin/compiler.rb:492:in `update_stylesheet'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/plugin/compiler.rb:215:in `block in update_stylesheets'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/plugin/compiler.rb:209:in `each'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/plugin/compiler.rb:209:in `update_stylesheets'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/plugin/compiler.rb:473:in `on_file_changed'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/lib/sass/plugin/compiler.rb:331:in `block in watch'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/vendor/listen/lib/listen/listener.rb:252:in `call'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/vendor/listen/lib/listen/listener.rb:252:in `on_change'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/vendor/listen/lib/listen/listener.rb:290:in `block in initialize_adapter'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/vendor/listen/lib/listen/adapter.rb:254:in `call'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/vendor/listen/lib/listen/adapter.rb:254:in `report_changes'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/vendor/listen/lib/listen/adapter.rb:323:in `poll_changed_directories'
/Library/Ruby/Gems/2.0.0/gems/sass-3.4.22/vendor/listen/lib/listen/adapter.rb:299:in `block in start_poller'
*/

对比几个出错的css文件，可以从中提取出特征：都有Error:和Backtrace:这两个字符串。那么可以通过这个特征来检测css文件是否出错。

回过头来想一下，其实用第一种方法是比较冗余的，因为我们只是为了找错，而不是想再编译一遍，这会产生性能上的差异，尤其当集中对每一个repo进行编译的时候，性能问题凸显，除非分发到pre-commit或者CI阶段，但是又会产生之前提到过的问题。

所以最终选择的方案是：在部署阶段，检测指定的css是否出错，若出错进而反推出相应的scss文件。

实现

文件遍历部分就不提了，用gulp实现很简单。

css检测脚本（基于gulp）:

var through = require('through2');
var gutil = require('gulp-util');
var path = require('path');
var PluginError = gutil.PluginError;

const PLUGIN_NAME = 'gulp-isErrorInCSS';

function isErrorInCSS(prefixText) {
    var errors = 0;

    // 这里添加highWaterMark是因为默认只能遍历16个还是32个文件
    return through.obj({highWaterMark: 999999}, function (file, enc, cb) {
        if (file.isNull()) {
            return cb(null, file);
        }
        if (file.isBuffer()) {
            // 判断css文件内容里是否同时存在Error:和Backtrace:字符串
            if (file.contents.toString().includes('Error:') && file.contents.toString().includes('Backtrace:')) {
                // 给出出错css文件的相对路径
                console.warn('Error In:' + path.relative('.', file.path));
                errors++;
            }
        }

        cb(null, file);
    }, function (cb) {
        if (errors) {
            throw new PluginError(PLUGIN_NAME, errors + '个css出错！请到对应的源文件改正');
        } else {
            console.log('css没有出错');
            cb();
        }
    });

}

module.exports = isErrorInCSS;