search

CSSLint / csslint

Automated linting of Cascading Stylesheets
http://csslint.net
Other
4.77k stars 483 forks source link

CSSLint + Stylelint #668

Open ai opened 8 years ago

ai commented 8 years ago

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

  5. More developers will work for one tool — so less time for boring support tasks and more for developing new smart rules.
  6. 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.
  7. 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.
  8. 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.
  9. 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

  10. 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
  11. They will get SCSS and Less support.
  12. With Stylefmt they will be able to fix CSS automatically according to linter rules.
  13. They will be able to parse CSS once for Autoprefixer and linter. Parsing is the longest part of CSS tools.
  14. They will have postcss-browser-reporter.
  15. Also people like modular architecture for linters — ESLint is the great example. Stylelint based on same ESLint modular philosophy.
  16. 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.
jeddy3 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 7 years ago

@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.

alexander-akait commented 7 years ago

@seth2810 can you PR in our repo?

seth2810 commented 7 years ago

@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: