Use Stylelint to check Css_stylelint_ basics

When you write a large number of CSS code, there may be more than one error. You may need a tool to prevent errors in your CSS writing.

Maybe, sometimes your mistake is really a bug. There may be inconsistencies or ambiguous code styles simply caused by haste. Many of them may seem trivial (depending on your temperament), but as the code base increases and time accumulates, many people make ugly things when they use them. The consequences of things are not as you can imagine.

You try to control yourself. Your colleagues also help you when you are free to correct your mistakes in a timely manner. However, you and your co-workers are the wrong makers, so at least to some extent they inevitably fail. Later, you or someone else is going to solve the problem caused by CSS errors on your page.

Neither you nor your co-workers like to discuss your mistakes because it's embarrassing. Sometimes it can be frustrating, or even emotionally fractured. Certain specifications are sometimes helpful for maintaining code libraries, such as consistent writing styles, which may seem pedantic when executed manually. Or they will show you what you normally like, pushy, stubborn elements.

In addition, you may prefer to fix errors in a timely manner instead of waiting for the code to be reviewed, and then make your own changes and declare that no such errors will occur. When your CSS is wrong, a timely feedback will help you save a lot of time.

All you need is a machine that prevents errors from being created.

You need a machine to prevent errors, to understand CSS and to understand you: your intentions, preferences, ideas, and weaknesses.

This machine will have limitations. All things are not perfect. But the limitations are different from you and your co-workers. As long as it can stop the mistakes it will continue to stop, tireless. At the same time, you and your colleagues can always improve the machine, expand its functionality and weaken its limitations. It's open source, and people all over the world can join in and do their part-other authors who want to stop themselves from having CSS writing errors.

CSS authors, as well as others, need linters

We call these programs that prevent errors to be called "linters." There are several better linter in JavaScript. Eslint, in particular, has played a miraculous role in showing us that a good linter is so useful. But in CSS, we are not so lucky, our choices are very limited: based on Ruby, scss-lint with special preprocessor and older CSS Lint.

But it was before the Postcss appeared. In addition, POSTCSS provides a number of ways to build more interactive CSS tools. It can parse and manipulate any class CSS syntax into an abstract syntax tree (AST) plug-in. And with a custom parser, POSTCSS can even handle invalid schemas that are not canonical (such as // annotations)

Mature conditions can already produce a more powerful Linter-based on POSTCSS's powerful capabilities and inspired by Scss-lint and Eslint best features.

I'm working on this project with a couple of small partners, and now I'm going to start by introducing the tools we've developed: Stylelint.

Use Stylelint what you can do

Here's a summary of the features that are being tried on stylelint, where the rules are up to Baiyu and scalable.

At this point, if you find yourself getting a little impatient ("Ok,ok: I believe Stylelint will have a miraculous working effect." There is no need for too many summaries. ")。 Just skip to the next section, where I'll just explain some of the questions and provide some hints.

Error capture

Some stylelint rules are designed to identify obvious errors, such as spelling mistakes or omissions that are made when you are distracted or sleepy. For example, you can ban whitespace blocks, invalid hexadecimal values, duplicate selectors, unnamed animated names, and incorrect linear gradient syntax.

Other rules are to try their best to catch more subtle errors. Here's a rule: when you use a shorthand attribute that can overwrite its attribute peers (such as) margin-top , a margin warning is issued, because it may have been caused by your negligence. In addition, there is a rule that warns you that when chaos occurs, rule a appears before rule B, but it actually overrides rule B because the selector for rule A has a higher priority (for example, rule A is .foo.bar{···} , Rule B is .foo{···} ). This is a very tricky situation.

There is also a rule that uses the Postcss Doiuse plug-in to check whether your browser supports this style. The other uses a Css-colorguard plugin to hint at the similarity of colors to avoid confusing use. (Note: This is based on Postcss Stylelint one of the main advantages: compared to other postcss plug-ins, with little effort, stylelint can be prompted. )

Enforcing Best Practices

If you use a system method in your stylesheet, or you set a style guide to your code, you should eliminate these patterns. Stylelint has already provided these features.

First, you need to ruthlessly control your selector. With Stylelint, you can prohibit more than a certain specific selector or set a limit on the nesting depth. You can disallow category selectors (for example, selectors that do not have IDs) and use regular expressions to name conventions for the rest of the selectors.

You can ban !important the use, or your browser does not support the Brower hacks. If you use Autoprefixer (or you should), you can disable the use of the vendor prefix in the source style sheet.

If you want to be more rigorous-you can spend some time on configuration to ensure absolute consistency-you can enforce the order of style sheet attributes and provide attributes, values, functions, and units for the blacklist, whitelist.

Conventions for executing code styles

Stylelint has the convention of automating Code styles, so you and your teammates don't need to set up the initiative. We are committed to making these rules more comprehensive and flexible.

These rules are primarily for spaces, but also for other details, such as quotation marks, uppercase and lowercase letters, 0 before decimals, use of keywords, spelling out values, and so on.

Dream that you and your teammates can create a format convention (for example, we always leave a space after declaring a colon) and modify it in your stylelint configuration, and then you won't discuss it again. Let it be carried out in the machine kingdom.

Develop and expand everything

The creator of Nicholas Zakas,eslint (and CSS Lint) writes that Eslint's success lies in its extensibility. Stylelint tries to follow Eslint's lead and gives CSS authors a linter, as well as extensibility.

You can write and publish your own rules plugin. Now we have a whole lot to work with, and we are eager to see other people's good plug-ins.

The configuration is extensible and can therefore be shared. As for Plug-ins, we know the value of this function from Eslint. Check which includes WordPress and SUITCSS configuration, and has been published.

If you don't like Stylelint's built-in tips, you can create your own style by hand and even create for your organization. You can also customize the rules used to provide warning messages.

Using the Stylelint API, you can create a text compiler plug-in and test the stylelint into every aspect of your workflow.

If you have ideas about Stylelint expansion, please let us know!

The answer to the expected question

There may be a few questions in your mind. Here are some of the most common questions to explain:

Can I use Stylelint in scss or less?

The answer is yes, you can use Stylelint in Scss, and also get support in less! Since POSTCSS allows custom parsers, Stylelint can easily support a wide variety of non-standard syntax-you can customize a POSTCSS parser for parsing.

Because of the POSTCSS parser-so stylelint supports scss,less and new Sugarss. If you want to implement another custom syntax support, you can achieve it through postless!

Of course, there are certain rules that get stuck in front of your non-standard syntax (such as confusing the Sass ID selector #{$interpolation} ). Because Stylelint is trying to hide the style of our style sheets-some people use standard CSS, some use extended languages like scss, some use weird custom attributes, and so on-which inevitably create vulnerabilities that need to be filled. However, we have been dealing with the errors we have found, during which any rule can be completely closed or disabled by successive stylesheets or successive rows.

Stylelint can I use future CSS syntax?

Yes! Similar to the answer described above: Stylelint can understand anything that POSTCSS understands, including enabling any future CSS syntax (possibly through the POSTCSS plug-in). In fact, some stylelint rules deal specifically with future CSS syntax and some custom attributes.

Stylelint configuration is huge, where should I start?

We recommend three ways of configuring:

Extends the configuration of a publication. We maintain stylelint-configuration standards so that we can provide an intrinsic benchmark for our users. And many of the configurations have been announced. Start from the beginning and add one rule at a time. By default, no rule is turned on, so by manually adding a rule you know which one will be enforced, and you can understand every rule you add. Initiates the copy and paste configuration, determines which options are used, and optionally deletes them.

Thankfully, you don't need to write a huge stylelint configuration over and over again. You can choose a style that you like and can use it anywhere.

The easiest way to run Stylelint?

For most people, the easiest way to do this is through its command line.

If you prefer Gulp plug-ins, you can use Gulp-stylelint. For Webpack, there are many possibilities for choice. We hope these plug-ins will inspire you to create other Stylelint plug-ins, for example, for grunt plug-ins. (You can find it in the Open source project!) )

You can also use the POSTCSS plug-in to run Stylelint, including anything contained in the plugin. This means that you can use stylelint! in any place where you can use POSTCSS (almost every compilation tool)

In addition, there is a stylelint text compilation plug-in for Atom,sublime Text,vs code to provide the fastest feedback. For more information, consult the list of complementary tools on the Stylelint Web site.

As shown below, the results you expect to see on the command line:

Shown in Atom as follows;

Can stylelint fix my mistakes?

No, but another called STYLEFMT is designed to do this. It requires a stylelint configuration-very similar to what you use in linting-and can fix any errors. We hope that with the contribution of Community personnel, Stylelint can be developed to automatically fix errors that violate stylelint rules. Please help them achieve this goal!

You can also use other tools, such as Csscomb or perfectionlist that are used in conjunction with Stylelint, to automatically repair and automatically force a break.

Using Linting for constraint supplementation

There is a huge amount of constraint in a good CSS. That's why we spend a lot of time discussing Smacss, AcSS, BEM, Suitcss, Itcss, and so on. We all know that writing bad CSS is very easy, so if we are not afraid of CSS style writing, we need to build an intelligent strategy in our work and stick to it bravely.

Stylelint's goal is to automate--provide a set of core rules and a pluggable framework for CSS authors to use to implement their own strategy.

Give it a try and let us know how to serve you. If you have related better ideas for improvement, such as contributing rules, enhancements, testing, fixing bugs, files, new ideas, or just feedback, please give us a raise! So that all of our level of developers have a job to do.