New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSSLint + Stylelint #668

Open
ai opened this Issue Jul 22, 2016 · 57 comments

Comments

Projects
None yet
@ai

ai commented Jul 22, 2016

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

This comment has been minimized.

Member

XhmikosR commented Jul 22, 2016

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" notifications@github.com 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
#668, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVVtWwFHkRPNoMR0U-0A7i1653Gxl7Wks5qYM9VgaJpZM4JSy1b
.

@ai

This comment has been minimized.

ai commented Jul 23, 2016

@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

This comment has been minimized.

maraisr commented Jul 23, 2016

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

@Xaviju

This comment has been minimized.

Xaviju commented Jul 23, 2016

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

@yepninja

This comment has been minimized.

yepninja commented Jul 23, 2016

I am ready to help, too.

@mjovel

This comment has been minimized.

mjovel commented Jul 23, 2016

Happy to help!

@ai

This comment has been minimized.

ai commented Jul 24, 2016

@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

This comment has been minimized.

davidtheclark commented Jul 24, 2016

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

This comment has been minimized.

maraisr commented Jul 24, 2016

@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

This comment has been minimized.

davidtheclark commented Jul 24, 2016

@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

This comment has been minimized.

ai commented Jul 24, 2016

@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

This comment has been minimized.

davidtheclark commented Jul 24, 2016

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

This comment has been minimized.

maraisr commented Jul 24, 2016

@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

This comment has been minimized.

jeddy3 commented Jul 24, 2016

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:

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

This comment has been minimized.

delorge commented Jul 24, 2016

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

@Kirbaba

This comment has been minimized.

Kirbaba commented Jul 24, 2016

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

This comment has been minimized.

ai commented Jul 24, 2016

@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

This comment has been minimized.

Member

nschonni commented Jul 25, 2016

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

This comment has been minimized.

ai commented Jul 25, 2016

@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

This comment has been minimized.

ai commented Jul 25, 2016

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

@davidtheclark

This comment has been minimized.

davidtheclark commented Jul 25, 2016

@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

This comment has been minimized.

Kirbaba commented Jul 26, 2016

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

This comment has been minimized.

ai commented Jul 26, 2016

@alanev did his part too, but create for it separated issue #669

@ai

This comment has been minimized.

ai commented Jul 26, 2016

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

@delorge

This comment has been minimized.

delorge commented Jul 26, 2016

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

@davidtheclark

This comment has been minimized.

davidtheclark commented Jul 26, 2016

@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

This comment has been minimized.

Xaviju commented Jul 26, 2016

I'm working on my task, it should be ready today, sorry 👍

@delorge

This comment has been minimized.

delorge commented Jul 26, 2016

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

This comment has been minimized.

Xaviju commented Jul 26, 2016

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

This comment has been minimized.

mjovel commented Jul 26, 2016

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

@frvge

This comment has been minimized.

Contributor

frvge commented Jul 27, 2016

I'm mostly just helping out with basic stuff/triage/quick-fixes. I leave the decisions up to the others.

@maraisr

This comment has been minimized.

maraisr commented Jul 27, 2016

@delorge thank you for the overview! We're getting close guys!

@evilebottnawi

This comment has been minimized.

evilebottnawi commented Jul 28, 2016

@delorge

  • box-sizing -> property-blacklist
  • shorthand i can help with rules, maybe good for stylelint core rules
  • floats and font-sizes, i have idea create rule max-declaration-property (maybe better name) for controlling max properties in styles, example be good disable many animation
@evilebottnawi

This comment has been minimized.

evilebottnawi commented Jul 28, 2016

@delorge also i don't understand what need reworked/updated in rules:

  • import -> at-rule-blacklist
  • regex-selectors -> selector-attribute-operator-blacklist
@davidtheclark

This comment has been minimized.

davidtheclark commented Jul 28, 2016

I suggest as a next step to open individual issues in stylelint for each rule or option that you think should be added. We could also open issues for individual plugins, either there or here, now or later. That way we can discuss each case in its own individual issue. I think that will be more effective than trying to address them all here in this one thread.

@evilebottnawi

This comment has been minimized.

evilebottnawi commented Jul 28, 2016

@davidtheclark maybe open one issue CCSLint compatibility with all rules CSSLint rules and step by step open issue on rules?

@maraisr

This comment has been minimized.

maraisr commented Jul 28, 2016

@davidtheclark i tend to agree, the issues will allow us to in effect keep track of progress!

@Kirbaba

This comment has been minimized.

Kirbaba commented Jul 28, 2016

1. Need to write:

  • adjoining-classes
  • box-model
  • box-sizing
  • text-indent
  • fallback-colors

2. Need to extend or rewrite:

  • no-browser-hacks -> start-property-hack + underscore-property-hack
  • declaration-block-no-ignored-properties -> display-property-grouping
  • declaration-block-no-duplicate-properties -> duplicate-propertie
@delorge

This comment has been minimized.

delorge commented Jul 29, 2016

@evilebottnawi I didn't examine most of the rules, I just put everything in order :)

import -> at-rule-blacklist regex-selectors -> selector-attribute-operator-blacklist
You better ask @Xaviju about that.

@delorge

This comment has been minimized.

delorge commented Jul 29, 2016

@evilebottnawi agreed with box-sizing, moving this rule to update category.

@Xaviju

This comment has been minimized.

Xaviju commented Jul 29, 2016

@delorge @evilebottnawi I don't think they need to be rewritten. Both at-rule-blacklist and selector-attribute-operator-blacklist are more powerful and already include the same options than CSSLint. I just pointed out that are not exactly similar.

@delorge

This comment has been minimized.

delorge commented Jul 29, 2016

@Xaviju alright, moving this to deprecated category

@evilebottnawi

This comment has been minimized.

evilebottnawi commented Jul 29, 2016

Move to stylelint/stylelint#1739, let's go

@evilebottnawi evilebottnawi referenced this issue Jul 29, 2016

Closed

CSSLint compat #1739

9 of 31 tasks complete
@jeddy3

This comment has been minimized.

jeddy3 commented Jul 29, 2016

I suggest as a next step to open individual issues in stylelint for each rule or option that you think should be added. We could also open issues for individual plugins, either there or here, now or later. That way we can discuss each case in its own individual issue.

Sgtm. I suggest creating the plugin issues in this issue tracker and the rule issues (that meet the criteria) in the stylelint issue tracker, so that the separation of responsibilities is maintained.

@nschonni

This comment has been minimized.

Member

nschonni commented Aug 1, 2016

@ai

CSSLint and Stylelint are both functional linting. Am I right?

Yup, definitely. The point I was making was that JSCS and ESLint wasn't 2 functional linting projects merging.

Yeap, npm size is always problem right now. But I think most of users prefer more rules, than less file size.
PostCSS and Stylelint definitely support node.js and browser.

Is there a standalone web version? The web version I saw on the site looks like it requires a backend.

I supported Java/Rhino, but have no good tests right now. Could you recommend Travis CI solution, to test PostCSS/Stylelint with Rhino?

No, I couldn't find a good way of pulling down Rhino in a build matrix, but it has been awhile since I looked. We had problems because of bugs in the last official release (when I looked), but were fixed in the unreleased version.

What is WSH?

Windows Script Host

@ai

This comment has been minimized.

ai commented Aug 1, 2016

@nschonni

Yup, definitely. The point I was making was that JSCS and ESLint wasn't 2 functional linting projects merging.

Sure, JSCS and ESLint had more differences. But I think that idea difference is main reason against merging. If some project has some idea, they should merge to solve this idea in the best way.

Is there a standalone web version?

Just use browserify or webpack to build client side. Most of PostCSS plugins are client side ready.

We had problems because of bugs in the last official release (when I looked), but were fixed in the unreleased version.

How did you test it? We could implement this testing in Stylelint too.

But, honestly there was no WSH/Rhino issue reports in entire PostCSS ecosystem (it is much bigger) — seems like most of users was migrated to node.js.

@jeddy3

This comment has been minimized.

jeddy3 commented Aug 3, 2016

@delorge Thanks for the summary!

@davidtheclark wrote: I suggest as a next step to open individual issues in stylelint for each rule or option that you think should be added. We could also open issues for individual plugins, either there or here, now or later. That way we can discuss each case in its own individual issue. I think that will be more effective than trying to address them all here in this one thread.

Over at stylelint we've created new issues for the rules and options that we think should be added to core. That leaves the following plugins up for discussion outside of the stylelint organisation:

Possible Errors

Compatibility

Performance

Maintainability & Duplication

Accessibility

OOCSS

Whoever wants to lead the stylelint-csslint plugin pack initiative, I'd recommend creating a new stylelint-csslint repo (within the CSSLint organisation). Then creating separate issues for each of these plugins. Some of these issues will be closed quickly as there are some thoughts that a few of the rules are outdated and should be deprecated. Having the decisions made, however quickly, within separate issues allows people to comment cleanly on the matter though, and keeps everything easy to reference.

In terms of inspiration of what a plugin pack might look like, I suggest checking out stylelint-scss.

From this point forward, I suggest this issue should focus on discussing the merits of different merge/migration paths e.g. @ai's suggestion of:

npm install stylelint-csslint stylelint; stylelint-csslint convert ./

If a conversion CLI tool bundled within stylelint-csslint proves to be the path forward, we can close this issue and create an new issue within the stylelint-csslint repo to discuss the details of the implementation.

One advantage I can think of the conversion tool is that current CSSLint can remain available for anyone wishing to use rules deemed outdated in stylelint-csslint or has one of the use cases that @nschonni outlined.

@seth2810

This comment has been minimized.

seth2810 commented Dec 9, 2016

@jeddy3 I can participate stylelint-csslint initiative. I started with implementation a couple of rules, currently without tests and build pipe, that currently are most needed for me inside personal repo, but I am pleased to share my current code base for community.

@evilebottnawi

This comment has been minimized.

evilebottnawi commented Dec 10, 2016

@seth2810 can you PR in our repo?

@seth2810

This comment has been minimized.

seth2810 commented Dec 10, 2016

@evilebottnawi I don't understand what you mean. Of course I can make PR in your repo, but I think it is about creating a separate repo for missing rules. It would be great if the solution would work in both directions:

  • use stylelint-csslint-missing inside new CSSLint core;
  • ease migration from CSSLint with plug-in and configure couple of missed rules inside Stylelint configuration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment