2.0 Roadmap

[Snugug]

This is a tracking issue for 2.0, describing the roadmap.

• Update to latest Gonzales (including updating rules as needed)
• Move to single traversal for iterating over the AST
• Introduce pluggable rules from node modules
• Introduce pluggable config (a la ESLint)
• Rule Name Cleanup
• SDTIN for CLI

[Snugug]

Okay, here are the things that I'm thinking about for our 2.0 roadmap. If I've missed something, please LMK, and we should track these with related issues

[bmds]

Is there a timeline for Gonzales being updated? That's the main blocker for adoption for a few of us at the minute

[DanPurdy]

Unfortunately we're still waiting for some of the gonzales issues in 3.2.1 to be fixed, we've not seen any updates to gonzales for a while so I imagine the developer is too busy at the moment. Unfortunately there's not much we can do about it right now until that situation changes... 😢

[bmds]

@DanPurdy no worries. We currently use https://github.com/brigade/scss-lint but it would be nice to remove our Ruby dependency.

[DanPurdy]

Id like to add processing STDIN with the CLI to 2.0 and also unit testing on top of the integration tests we already do.

[DanPurdy]

As this is a breaking change we should also take the opportunity to rename any of the rules etc and give everything the once over.

[Snugug]

Agreed.

[DanPurdy]

Updating the CLI to work the same way as eslint in regards to logging errors by default and introducing a silent flag would also be good here as we've discussed it briefly before.

[DanPurdy]

I'd like to include proper error codes on top of the work done with #458, the list that scss-lint throws seems like a good starting position.

We should also try to stop throwing unhandled errors wherever possible and instead just push them out as either parse errors or plugin errors as I've started in #459

[glen-84]

I chose sass-lint instead of scss-lint in order to avoid the Ruby dependency. Also, not knowing Ruby means that it would be difficult to add custom rules. However, I'm starting to get a bit concerned.

The following issues are quite significant, and limit the utility of this tool:

1. CLI should provide a list of errors and exit with the appropriate exit code #221 – for Git hooks and CI, we need a list of warnings/errors and a non-zero exit code.
2. Feature Request: Enable Disabling Linters via Source #70 – it's not going to be long before we need to disable certain linters for various reasons.
3. Pluggable Rules #139 – we would like to be able to easily add custom rules.
4. I believe that we need STDIN support for a Git hook.

Also, it's worrying that gonzales-pe hasn't had a commit in nearly 3 months.

I really don't want to have to use scss-lint if it can be avoided.

BTW, I find the configuration format rather unintuitive. For example:

space-after-bang: 1
space-before-colon: 1

A 1 usually represents true, so if you haven't read through the docs, this looks like you want a space after a bang and before a colon, or perhaps even looks like you're setting the number of spaces. What do you think of this format?:

options:
  default-severity: 1
rules:
  space-after-bang:
    severity: 2
  variable-name-format:
    severity: 2
    allow-leading-underscore: false
  another-rule: ~
  one-more-rule: ~

(~ is null in YAML)

Instead of having the options and severity together, you might also consider an options key with an array of objects containing key/value pairs, but this might be too verbose.

Might be something to consider for v2.0.

Anyway, I appreciate the work that you do, I just hope that it will be suitable for our needs.

[Snugug]

For pluggable config and rules, I built a thing for work for arbitrarily require-ing dependencies that we should look at:

https://github.com/Snugug/plugabilly

[amccloud]

A 1 usually represents true, so if you haven't read through the docs, this looks like you want a space after a bang and before a colon, or perhaps even looks like you're setting the number of spaces. What do you think of this format?:

@glen-84 Looks like they are just copying eslint's config format.

[glen-84]

@amccloud,

True, although you can also use strings for severity with ESLint ("error", etc.). I think that this is a relatively new enhancement though (link), so perhaps the same thing could be supported by sass-lint?

[DanPurdy]

It would be nice to update to use this yes. Internally though eslint is just transforming them back to 0, 1, 2 so it's just an abstraction. No reason we couldn't move to this model though.