Question: Interested in pooling our efforts?

[benedfit]

Hey, I've also been working on a Jade linter and style checker; https://github.com/benedfit/jadelint. My plan was to be non-opinionated and provide users with a means to set their own rules.

To cut to the chase, I'm disappointed that I've missed the boat and not snapped up jadelint on npm for my linter, so I was wondering if you were interested in pooling our efforts, and porting over some of the rules you have already created into more generic ones (e.g. DontUseBTags, DontUseSTags, etc, could be reengineered into disallowTags: [ 'b', 's' ]), in order to create a tool that the whole community can enjoy and use in a way that suites their individual needs?

[rrdelaney]

@benedfit I would definitely be interested.

And just for reference, a lot of my rules are created so they can be individually disabled without knowing how the internals of any rule works, e.g.

{
    "DontUseBTags": "ignore",
    "DontUseSTags": "warning"
}

as opposed to

{
    "disallowTags": ["s"]
}

I am definitely going for a more opinionated approach though, taking a lot of rules from https://github.com/hail2u/html-best-practices and https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Obsolete_things_to_avoid.

Even though my linter is opinionated, it is easy to disable rules by creating a .jadelintrc file and enabling/disabling rules. Although the documentation isn't automatically uploading right now, you can see a list of rules and defaults by cloning the repo and running grunt dist doc.

[benedfit]

Cool, I've just added disallowSpecificTags(https://github.com/benedfit/jadelint/blob/master/test/rules/disallow-specific-tags.test.js) as an illustration of how I was thinking of replicating you 'DontUse' rules. My rules are also optional, and they are only ever tested if they are add to (the yet to be developed) .jadelintrc (snap :smile:) file

Before you commit to anything, I'd like to go ahead and make sure I can replicate your current setup as a preset, and prove that my less opinionated plans, can be configured to achieve everything you have already achieved with this repo

[rrdelaney]

I strongly believe in a strongly opinionated linter, it should tell you what could go wrong and where.

In addition, my rules are easily configurable, and require no reading the documentation other than knowing the name of the rule, similar to other popular linters. This isn't to discredit the idea of a highly extensible linter that can be configured by the end-user in a very custom manner. I plan to support custom rules soon.

My project is taking heavy inspiration from https://github.com/rossPatton/stylint and https://github.com/clutchski/coffeelint

[benedfit]

Yes there's definitely place for both types of linter, I've been heavily inspired by jscs, but will definitely be implementing the same naming convention rules as stylint as we also use that in our dev stack

Best of luck with your continued development :smile:

[rrdelaney]

If you want to collaborate, I'd be more than happy to, but I do prefer rule styles like mine with an extensible core.