Switch from sass-lint to stylelint

[randycoulman]

Stylelint seems to be more popular, more flexible, and more future-proof than sass-lint. Also, it doesn't bring in a dependency on an old version of eslint, which is tripping us up a bit on the create-react-app 1.0 upgrade.

Also, consider modifying our react-scripts fork to bring in stylelint and use stylelint-webpack-plugin in a similar way to the eslint-loader. That way, we can get style linting feedback in the same places as we get code linting.

[frank-west-iii]

@randycoulman, we have this mostly done, but we have BC setup to use https://github.com/JaKXz/stylelint-webpack-plugin which is much nicer to see lint warnings in webpack-dev-server while you are coding.

If we wanted to use this it seems like all of the linting would then have to go into the fork instead of here. Does that sound correct?

What are your thoughts on this?

[frank-west-iii]

Example output:

Compiled with warnings.


src/modules/settings/components/styles.scss
 5:3  ⚠  Expected content to come before height   order/properties-alphabetical-order



Search for the keywords to learn more about each warning.
To ignore, add // eslint-disable-next-line to the line before.

[randycoulman]

That seems to be what I was thinking up above when I wrote this issue.

Would it make sense to make the switch here and then have a follow-up effort on the react-scripts fork to also bring in the webpack plugin?

My uninformed thought is that we could at least allow stylelint to run from editors and as part of the validate task (and therefore on CI) without doing the webpack part, but then add the webpack part in the fork for a better developer experience. Or am I misunderstanding that? Would we have to undo work here in order to make the webpack part work later?

[frank-west-iii]

Blah... of course you did. I missed that part of the comment :headslap:

[randycoulman]

Sorry, didn't mean that to sound snarky. More like me trying to reload old context into my head.