Support for custom csslint rules

[jgable]

Support for custom csslint rules

[jgable]

I think that's a neat idea. I believe we could add custom rules to CSSLint from within the task. The tricky part is making it configurable in a nice way. As a start, we could just allow you to specify a function that get's passed the plugins reference of CSSLint.

lesslint: {
  all: {
    options: {
      customRules: function (CSSLint) {  CSSLint.addRule(...); }
      // Or, preferably you'd have this in another file
      customRules: require('./grunt/customLessRules.js')
    }
  }
}

Thoughts?

[cvn]

That would be ideal. This might be obvious, but being able to add multiple functions is desirable.

[jgable]

Well, your required file could require all your other files that have multiple functions.

[jgable]

Haven't forgot about this, but won't be able to get to it until next weekend probably.

[cvn]

Someone has submitted a PR to grunt-contrib-csslint for adding custom rules. It might be helpful as a reference. gruntjs/grunt-contrib-csslint#46

[davidparsson]

Any news on this? If I were to submit a PR that implements this, would that be included and released any time soon?

[jgable]

Sure, give it a shot and I'll make you an admin on the project if you want.

[davidparsson]

Thanks! I'll see what I can do.

[davidparsson]

I've managed to load rule files with Grunt style globbing patterns, like this:

lesslint:
  options:
    customRules: ['rules/**/*.coffee']
  src: ['less/**/*.less']

I'm however facing trouble when it comes to allowing different customRules configurations for different lesslint targets. This is because CSSLint is a singleton and as far as I can tell it provides no simple way to reset its state.

It would be possible to resolve this using a rather complex solution, but the easiest and least error-prone implementation would be to only allow users to configure the same set of custom rules for all targets. In other words, only allowing customRules under the task's global option block, not under targets' option blocks.

@jgable, what are your thoughts on this? If you have the time, please review my changes so far.

[jgable]

I took a look today and the changes look good. It's unfortunate we can't remove the specific rules we add in for each configuration section.

I found this issue related to removeRule that points to us being able to pass the explicit rules to the .verify call. It looks like we'd have to refactor our call to verify to always pass the default rules and then custom rule ids of the files matched in the customRules option.

[davidparsson]

Thanks @jgable! The discussion in that issue pointed me in a better direction, which is to disable the unwanted rules by configuration instead of removing them. This is implemented in my PR above.