A unified jadelint

[rrdelaney]

After thinking about it for a little, I do think creating a more universal jadelint would be better. Rather than having two competing linters, we can work together to make the best one possible. I think a merge is possible, because our rules don't really overlap, and you lint based on tokens, while I use the AST. It leads to a nicely varied rule set that check for both syntax errors and best practices.

[benedfit]

Hi @rrdelaney, sorry it's taken me a few

I'd be happy to get together and create a unified linter, and while I'm flexible on exactly how we go about structuring a combined linter and the technologies we use, there's still the sticking point of whether the rules we define should be opinionated or not.

My strong opinion is that we should provide developers and development teams with the means to define their own best practices. For example, instead of adding one rule that disallows tag X and a second rule that disallows tag Y, we should provide one rule that can be configured to disallow both X and Y, but also A, B & C should the developer wish. In addition to making the tool less opinionated, this approach also reduces the need for the developers to code additional tests should they wish to disallow further tags that any preset we may not cover

One way for us to navigate this impasse, would be to create a preset configuration file that replicated the current rule set you have (adding the rules that I don't currently have in a configurable manner)

e.g. To disallow the tags your DontUseXTags rules disallow and HTMLRootRequiresLang

{ "disallowSpecificTags": [ "b", "hgroup", "i", "s", "u" ]
, "requireSpecificAttributes":
  [ { "html": "lang" }
  ]
}

What are you're thoughts on this approach?

Cheers

[rrdelaney]

I think I have a solution that works best for both of us.

Rather than turn specific rules 'on' or 'off', or setting rules directly, we can do what coffeelint does and allow each rule to be configured individually. For example, the DontUseX would become

{
  "DontUseDeprecatedTags" : {
    "tags": ["b", "s", "u"]
  }, 
  "HTMLRootRequiresLang": {
    "level": "ignore"
  }
}

and so on. Would that work for you? We would have to decide what rules should be generalized to having inputs though, and what should be an unconfigurable rule.

[benedfit]

Currently all rules in jade-lint are optional, and are only activated once they are present in the config, this is something I plan to continue. Check out the README to see which rules are configurable and which are just 'enabled'

Rather than talking this to death and going around in circles, if you'd like to contribute then please feel free to submit pull requests for some of the tests from jadelint that I currently don't have an equivalent of. This will give you more of a feel for how I've developed the rules to date, and will help to set the ground work for how we work together moving forward (which I really would like :smile:)

[ghost]

Currently all rules in jade-lint are optional, and are only activated once they are present in the config

My 2¢ -- This works better when you provide a starting point. eslint, for example, has base rule sets. You can set your linter to "google", "airbnb", etc, and it will use that rule file as a default and stick any rules in .estlintrc on top.

I don't like the idea of assuming that your average user has the necessary knowledge or desire to configure every option in a linter, but at the same time you don't want to restrict those options.

[benedfit]

@zyklus thanks for your input. This is something that I'm providing via presets (https://github.com/benedfit/jade-lint/tree/master/presets). Currently there is only one, these are the preferences of the agency that I work for, but the plan is that in time, and once all of the base rules are in place, that others will submit their own presets, and users will either be able to choose the preset via the command line, or as they currently can create a .jade-lintrc in a similar vain to the following:

{ "preset": "clock",
  /* Add overriding rules below */
  /* e.g. */
  "disallowBlockExpansion": true
}

[rrdelaney]

I don't really thing me just pushing my changes upstream is a very good solution. I think we should work together and decide on something that will work for both of us, because there are several thing in your project I disagree with, and I'm sure there's thing in mine you don't like.