CSSLint + Stylelint

[ai]

I think if we will merge CSSLint and Stylelint everyone will win — users will get more features, and we will have more free time. We already have great examples of ESLint + JSCS, Babel + esnext, Rails + Merb.

@XhmikosR @frvge @davidtheclark @jeddy3 what do you think?

Merging Plan Example

1. CSSLint developers will get a membership in Stylelint core team.
2. We check Stylelint rules and rewrite missed CSSLint plugin in Stylelint.
3. CSSLint 2.0 will use Stylelint as backend, but work with same old CSSLint config (it will convert CSSLint config to Stylelint config inside)
4. We provide some migration tool to convert CSSLint config to Stylelint config.

Benefits for CSSLint Developers

1. More developers will work for one tool — so less time for boring support tasks and more for developing new smart rules.
2. You will be a bigger project maintainer — more glory and respect. After merging, you will increase user base to 70%. Facebook, Github, US gov 18F, Wikipedia uses Stylelint. Bootstrap is in the migration to Stylelint.
3. Stylelint uses PostCSS — you will get many benefits from PostCSS ecosystem: SCSS, Less, Broken CSS and SugarSS parsers. There are useful development tools for PostCSS: rules benchmark and AST explorer. Autoprefixer brings a huge user base to be sure in CSS parser.
4. With PostCSS AST you could fix lint issues in CSS like eslint --fix does in JS. Stylelint already could do it for some rules with Stylefmt.
5. PostCSS parser is DOM-like, instead of SAX-like ParserLib. But with postcss-selector-parser, postcss-value-parser, and postcss-media-query-parser it will have same abilities for you.

Benefits for CSSLint Users

1. They will get more rules. Stylelint has around 150 rules including very smart: no-unsupported-browser-features, no-indistinguishable-colors, no-browser-hacks, no-descending-specificity
2. They will get SCSS and Less support.
3. With Stylefmt they will be able to fix CSS automatically according to linter rules.
4. They will be able to parse CSS once for Autoprefixer and linter. Parsing is the longest part of CSS tools.
5. They will have postcss-browser-reporter.
6. Also people like modular architecture for linters — ESLint is the great example. Stylelint based on same ESLint modular philosophy.
7. Users love when two awesome projects merge, so they are free from choosing what is best — for example, look at the reaction on ESLint + JSCS merge.

[XhmikosR]

Hey there.

All this seems nice, but personally I have very limited time at this point.

If there are developers willing to do this not just for a week, I'm totally in favor of this.

Unfortunately we lack of manpower. I tried getting out a stable release but I'm all alone and with limited time for CSS Lint.

On Jul 22, 2016 17:10, "Andrey Sitnik" [email protected] wrote:

I think if we will merge CSSLint and Stylelint http://stylelint.io/ everyone will win — users will get more features, and we will have more free time. We already have great examples of ESLint + JSCS http://eslint.org/blog/2016/04/welcoming-jscs-to-eslint, Babel + esnext https://babeljs.io/blog/2015/01/12/6to5-esnext, Rails + Merb http://yehudakatz.com/2008/12/23/rails-and-merb-merge/.

@XhmikosR https://github.com/XhmikosR @frvge https://github.com/frvge @davidtheclark https://github.com/davidtheclark @jeddy3 https://github.com/jeddy3 what do you think? Merging Plan Example

1. CSSLint developers will get a membership in Stylelint core team.
2. We check Stylelint rules and rewrite missed CSSLint plugin in Stylelint.
3. CSSLint 2.0 will use Stylelint as backend, but work with same old CSSLint config (it will convert CSSLint config to Stylelint config inside)
4. We provide some migration tool to convert CSSLint config to Stylelint config.

Benefits for CSSLint Developers

1. More developers will work for one tool — so less time for boring support tasks and more for developing new smart rules.
2. You will be a bigger project maintainer — more glory and respect. After merging, you will increase user base to 70%. Facebook https://code.facebook.com/posts/879890885467584/improving-css-quality-at-facebook-and-beyond/, Github https://github.com/primer/stylelint-config-primer, US gov 18F https://github.com/18F/stylelint-rules, Wikipedia https://github.com/wikimedia/stylelint-config-wikimedia uses Stylelint. Bootstrap is in the migration https://github.com/ntwb/stylelint-config-bootstrap to Stylelint.
3. Stylelint uses PostCSS https://github.com/postcss/postcss — you will get many benefits from PostCSS ecosystem: SCSS https://github.com/postcss/postcss-scss, Less https://github.com/webschik/postcss-less, Broken CSS https://github.com/postcss/postcss-safe-parser and SugarSS https://github.com/postcss/sugarss parsers. There are useful development tools for PostCSS: rules benchmark https://github.com/postcss/postcss-devtools and AST explorer http://astexplorer.net/#/np0DfVT78g/1. Autoprefixer brings a huge user base to be sure in CSS parser.
4. With PostCSS AST you could fix lint issues in CSS like eslint --fix does in JS. Stylelint already could do it for some rules with Stylefmt https://github.com/morishitter/stylefmt.
5. PostCSS parser is DOM-like, instead of SAX-like ParserLib. But with postcss-selector-parser https://github.com/postcss/postcss-selector-parser, postcss-value-parser https://github.com/TrySound/postcss-value-parser, and postcss-media-query-parser https://github.com/dryoma/postcss-media-query-parser it will have same abilities for you.

Benefits for CSSLint Users

1. They will get more rules. Stylelint has around 150 rules http://stylelint.io/user-guide/rules/ including very smart: no-unsupported-browser-features http://stylelint.io/user-guide/rules/no-unsupported-browser-features/, no-indistinguishable-colors http://stylelint.io/user-guide/rules/no-indistinguishable-colors/, no-browser-hacks http://stylelint.io/user-guide/rules/no-browser-hacks/, no-descending-specificity http://stylelint.io/user-guide/rules/no-descending-specificity/
2. They will get SCSS https://github.com/postcss/postcss-scss and Less https://github.com/webschik/postcss-less support.
3. With Stylefmt https://github.com/morishitter/stylefmt they will be able to fix CSS automatically according to linter rules.
4. They will be able to parse CSS once for Autoprefixer and linter. Parsing is the longest part of CSS tools.
5. They will have postcss-browser-reporter https://github.com/postcss/postcss-browser-reporter.
6. Also people like modular architecture for linters — ESLint is the great example. Stylelint based on same ESLint modular philosophy.
7. Users love when two awesome projects merge, so they are free from choosing what is best — for example, look at the reaction on ESLint + JSCS merge.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CSSLint/csslint/issues/668, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVVtWwFHkRPNoMR0U-0A7i1653Gxl7Wks5qYM9VgaJpZM4JSy1b .

[ai]

@XhmikosR sure, maintaining is hard. But this merging could dramatically help you with lack of manpower ;).

I will ask my followers to help.

I think the first task will be to compare CSSLint and Stylelint rules.

[maraisr]

I'm happy to help! So use me ☝🏻️

[Xaviju]

I'll be happy to help as well. Keep me informed!

[yepninja]

I am ready to help, too.

[mjovel]

Happy to help!

[ai]

@mjovel @alanev @Xaviju @maraisr Awesome! Also I have Kirbaba developer from Russia, who want to have.

First step is to check CSSLint rules — what we can already implement in Stylelint.

Here is CSSLint rules: https://github.com/CSSLint/csslint/wiki/Rules. I count 31 rules. We have 5 developers. Let’s everyone take 6 rules:

1. Kirbaba: box-model, display-property-grouping, duplicate-properties, empty-rules, known-properties, adjoining-classes
2. @maraisr: box-sizing, compatible-vendor-prefixes, gradients, text-indent, vendor-prefix, fallback-colors
3. @Xaviju: star-property-hack, underscore-property-hack, bulletproof-font-face, font-faces, import, regex-selectors
4. @alanev: universal-selector, unqualified-attributes, zero-units, overqualified-elements, shorthand, duplicate-background-images
5. @mjovel: floats, font-sizes, ids, important, qualified-headings, unique-headings

I need you to check every rule and mark it with:

• y — we can implement it one-to-one by existed Stylelint rules (please write what rules with what options). Also don’t forget to look to third-party rules, for example https://www.npmjs.com/package/stylelint-known-property
• x — we have similar rules in Stylelint, but we need to add some features or options (write what rules and what we need to add)
• n — we have no same rules in Stylelint.

[davidtheclark]

It's awesome that all of you stepped forward to help with this!

One of the things I imagine will need to happen during the course of development is the creation of a stylelint-csslint plugin collection. See stylelint-scss for a good existing example. A number of the CSSLint rules look like they'll end up in that plugin collection rather than in stylelint's core rule set (e.g. floats, unique-headings, etc.). We can talk about each individually, of course, but just clueing you all in to a part of the process I anticipate — something for someone to take charge of if interested.

[maraisr]

@davidtheclark yeah mate - I think its so amazing too!! My two cents are, I think that @ai wanted to iron out the discrepancy between having 2 toolsets that do roughly the exact same thing, and merge them into 1 toolchain, like JSCS and ESlint did.

[davidtheclark]

@maraisr Yep, sounds right! I'm not suggesting that the merge wouldn't involve enhancements to stylelint, if it sounded like that. Just suggesting that I think to full compatibility with CSSLint's rule set will involve a combination of enhancements to existing rules, new rules, and a stylelint-csslint plugin collection.

[ai]

@davidtheclark sure, we could put extra rules in different place if they are should not be stylelint core.

Also where we can find good third-party rules list (for CSSLint rules checking)?

[davidtheclark]

I don't think anyone's compiled a comprehensive list of third party rules. @jeddy3 might know more than me here. But I've relied just on npm searches to see what's out there --- kind of weak.

[maraisr]

@davidtheclark yeah - will be interesting! In my mind I see a "polymorphic" style approach, where by you can load both your long standing csslint, and or stylelint config file, with a general move toward a standard config.

[jeddy3]

It's awesome that all of you stepped forward to help with this!

Agreed. Thanks everyone!

Just suggesting that I think to full compatibility with CSSLint's rule set will involve a combination of enhancements to existing rules, new rules, and a stylelint-csslint plugin collection.

Agreed. To expand on what @davidtheclark said, rules are only included in core if they meet these criteria. This is to ensure development of the linter remains sustainable.

@jeddy3 might know more than me here. But I've relied just on npm searches to see what's out there

Plugin authors are asked to include the stylelint-plugin keyword in their package.json. Plugins that currently do so are listed here.

Bare in mind that around three quarters of these plugins are deprecated (or have pending deprecate issues) as they can now be handled by core rules e.g. the deprecated plugin stylelint-known-property → the core rule property-no-unknown. I believe the only viable plugins (that aren't already on our curated list of plugins) are:

• https://www.npmjs.com/package/stylelint-value-list-box-shadow-inset-first
• https://www.npmjs.com/package/stylelint-selector-pseudo-class-lvhfa
• https://www.npmjs.com/package/@namics/stylelint-bem

In my mind I see a "polymorphic" style approach, where by you can load both your long standing csslint, and or stylelint config file, with a general move toward a standard config.

Would a simple migration guide from CSSLint to stylelint (in the same manner as this one for scss-lint) not be the simplest option here? If someone feels adventurous they could create a standalone tool (and/or website) that converts a CSSLint config into a stylelint one.

Either way, I agree with @ai's first step. Once we have a better idea of what CSSLint rules are already achievable using stylelint, we'll be in a better position to decide what approach is best.

@maraisr @Xaviju @alanev @mjovel FYI, you'll find the complete list of stylelint's rules here. If you're not already familiar with stylelint you might find this guide about rules useful, as it explains the naming convention and how rules are designed to work together. There is also this part of the Developer Guide that details the option conventions we use. Good luck and please don't hesitate to holler if you've any questions about the workings and conventions of stylelint :)

[delorge]

I'm a bit late but I want to help as well :) guess I will join later

[Kirbaba]

1. The same Stylelint rules "empty-rules" is same as the "block-no-empty"

2. Similar rules in Stylelint, but we need to add some features or options: Stylelint "declaration-block-no-ignored-properties" is same as CSSLint "display-property-grouping" but

there is no rule for combination of inline-block displaying with float.

"duplicate-properties" is looks like "declaration-block-no-duplicate-properties" but there is nothing about checking properties which containing the same value. For example: CSSLint considered warnings for:

.mybox {
    border: 1px solid black;
    border: 1px solid black;
}

3. There is no same rules in Stylelint The CSSLint rules "adjoining-classes" and "box-model" doesn’t have the Stylelint analogs.

"known-properties" in the CSSLint is checking a value and ignoring all vendor-prefixes. Stylelint "property-no-unknown" is checking only property and isn't ignoring a prefixes.

[ai]

@jeddy3 awesome migration guide. But it doesn’t really work.

1. User should learn that there is Stylelint.
2. User should find this guide (I didn’t saw it, before you mention it).
3. User should find working time to do all steps manually.

As result we will have few % of users in the end of this funnel.

Of course for users will be much easy to just change "csslint": "^1.0.0" to "csslint": "^2.0.0" or run something npm install stylelint-csslint stylelint; stylelint-csslint convert ./.

[nschonni]

I'm more 👎 on this, but since I've been pretty dormant I'll go with what the other maintainers go with. Few points:

• JSCS merged with ESLint, not JSHint. CSSLint is more like JSHint than JSCS since it deals with functional linting not style-only rules.
• npm i csslint is 1.6MB vs. npm i stylint is 26MB
• CSSLint supports Node, Java/Rhino, WSH, and browser execution.

I will probably use Stylelint in new projects projects where it makes sense, just like I've transitioned some to ESLint where it makes sense. You folks are doing awesome stuff, and I've enjoyed the Autoprefixer for along time.

[ai]

@nschonni

1. CSSLint and Stylelint are both functional linting. Am I right?
2. Yeap, npm size is always problem right now. But I think most of users prefer more rules, than less file size.
3. PostCSS and Stylelint definitely support node.js and browser. I supported Java/Rhino, but have no good tests right now. Could you recommend Travis CI solution, to test PostCSS/Stylelint with Rhino? What is WSH?

[ai]

@delorge feel free to take someone rules task if they will not get review in this evening :)

[davidtheclark]

@nschonni @ai I don't know what "functional linting" refers to, and don't see a definition on a quick search. But I agree that there's a difference in approach. I wouldn't say that CSSLint is more like JSHint than stylelint, in trying to catch real code errors (both do that); and I also wouldn't say that stylelint is restricted to "style-only" rules (there are plenty of non-style rules). A distinction that does exist, I think --- and maybe this is what you're referring to --- is that CSSLint includes rules like "too many floats", which are more like provisional suggestions that you may override in code review rather than auto-enforceable rules. (Those are in fact the kind of rules that I think would make for better stylelint plugins than core rules.)

The reason for the merge would not be to stop enforcement of those CSSLint-specific rules (plugin collection would work), but to share infrastructure and maintenance, and possibly even extend those CSSLint-specific rules to a wider audience (e.g. SCSS users).

(Why are people worried about filesize for npm modules? Is it just download time when running npm install?)

[Kirbaba]

2. Similar rules in Stylelint, but we need to add some features or options:

Stylelint rule "no-browser-hacks" can be extended to include the CSSLint rules "start-property-hack" and "underscore-property-hack"

3.There is no same rules in Stylelint

• "box-sizing"
• "text-indent"
• "fallback-colors"
• "bulletproof-font-face" CSSLint "gradient", "compatible-vendor-prefixes", "vendor-prefix" doesn't have Stylelint analogs, but there is no needs because we have "Autoprefixer".

[ai]

@alanev did his part too, but create for it separated issue https://github.com/CSSLint/csslint/issues/669

[ai]

We need to check only @Xaviju and @mjovel rules pack and then we are ready to go to next step

[delorge]

@ai neither @Xaviju nor @mjovel showed up, I'll take @mjovel tasks

[davidtheclark]

@ai Thanks for organizing! What do you envision as the next step? One possibility would be to open issues for all the CSSLint rules the do not have already have direct substitutes so we can discuss how to handle each one individually.

[Xaviju]

I'm working on my task, it should be ready today, sorry :+1:

[delorge]

Existing Stylelint rules

1. ids -> selector-no-id
2. important -> declaration-no-important

CSSLint unique rules

1. floats
2. font-sizes

CSSLint rules I'm not sure about

1. qualified-headings
2. unique-headings

There are no such rules in stylelint, but selector-no-type dissalows

h3 {
    font-weight: normal;
}

and has an option to allow descendant type selectors which may cause conflict with this dissalowed declaration:

.box h3 {
    font-weight: bold;
}

I guess we need separate rules for these ones, but I don't know how to handle possible conflicts.

@ai @davidtheclark @jeddy3 any thoughts?

[Xaviju]

Disallow star hack

x Similar to no-browser-hacks

Stylelint disallow browser hacks that are irrelevant to the browsers you are targeting. Disallow star hack only points to this specific IE hack but stylelint option is more powerful.

underscore-property-hack

x Similar to no-browser-hacks

Same as above

bulletproof-font-face

n We have no same rules in Stylelint.

This rule is aimed at preventing 404 errors in Internet Explorer 8 and earlier due to a bug in how web font URLs are parsed.

font-faces

n We have no same rules in Stylelint.

Don't use too many web fonts

import

x Similar to At rule blacklist

This rule warns when @import is being used in CSS. In stylelint you can specify a blacklist of disallowed at-rules instead of a specific rule for import at-rule. Is more flexible.

regex-selectors

x Similar to selector-attribute-operator-blacklist

Disallow selectors that look like regular expressions In stylelint you can specify a list of disallowed attribute operators. If we leave it as it is in Stylelint, we will miss the useful recommendations of CSSlint on what are good and bad performance uses of this selectors.

[mjovel]

sorry. yesterday was a travel day. Thanks for picking my set up @delorge