Skip to content
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

Deprecate stylistic rules handled by Prettier #6504

Merged
merged 11 commits into from Dec 6, 2022
5 changes: 5 additions & 0 deletions .changeset/red-coins-rescue.md
@@ -0,0 +1,5 @@
---
"stylelint": minor
---

Deprecated: stylistic rules handled by Prettier
7 changes: 4 additions & 3 deletions README.md
Expand Up @@ -10,7 +10,7 @@ A mighty, modern linter that helps you avoid errors and enforce conventions in y

It's mighty as it:

- has over **170 built-in rules** for modern CSS syntax and features
- has over **100 built-in rules** for modern CSS syntax and features
- supports **plugins** so you can create your own rules
- automatically **fixes problems** where possible
- is **well tested** with over 15000 unit tests
Expand All @@ -32,14 +32,15 @@ It'll help you **avoid errors**, for example:
- unknown things, e.g. units and functions that aren't in the CSS specs
- valid things that are problematic, e.g. duplicated selectors and overridden properties

And **enforce non-stylistic conventions**, for example:
And **enforce conventions**, for example:

- what units, functions, at-rules etc are allowed
- consistent patterns for selector names, at-rule names, custom properties etc
- maximum specificity or maximum quantity of each selector type
- your preferred notation for color functions, font weight etc
- consistent empty lines before constructs

There are also rules for enforcing stylistic conventions, but we now recommend you use Stylelint alongside a pretty printer like Prettier. Linters and pretty printers are complementary tools that work together.
We recommend using Stylelint alongside a pretty printer like Prettier. Linters and pretty printers are complementary tools that work together to help you write consistent and error-free code that is well-formatted.

## Example output

Expand Down
2 changes: 1 addition & 1 deletion docs/about/vision.md
Expand Up @@ -14,7 +14,7 @@ A linter and validator for CSS that is:
Provide built-in rules for standard CSS syntax that:

- [avoid errors](../user-guide/rules.md#avoid-errors)
- [enforce non-stylistic conventions](../user-guide/rules.md#enforce-non-stylistic-conventions)
- [enforce conventions](../user-guide/rules.md#enforce-conventions)

## Extensible

Expand Down
19 changes: 19 additions & 0 deletions docs/developer-guide/rules.md
Expand Up @@ -6,6 +6,25 @@ Please help us create, enhance, and debug our rules!

You should get yourself ready to [contribute code](../../CONTRIBUTING.md#code-contributions).

### Define the rule
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Note] Pulled this out so that the list of rules is near the top of the page.


A rule must be:

- for standard CSS syntax only
- generally useful; not tied to idiosyncratic patterns

And have a:

- clear and unambiguous finished state
- singular purpose; don't overlap with other rules

It's name is split into two parts:

- the [_thing_](http://apps.workflower.fi/vocabs/css/en) the rule applies to, e.g. `at-rule`
- what the rule is checking, e.g. `disallowed-list`

Unless it applies to the whole source, then there is no first part.

### Write the rule

When writing the rule, you should:
Expand Down
68 changes: 57 additions & 11 deletions docs/migration-guide/to-15.md
@@ -1,12 +1,65 @@
# Migrating to 15.0.0

## Remove support for processors
This release contains significant and breaking changes that will help us modernize our code so that Stylelint remains free of security issues.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Note] Provide some context to changes. Doesn't go into the details of:

  • needing to migrate to ESM so we can keep as dependencies up to date
  • we have limited resources and time to make that migration


We removed the support for processors. Instead, please use [custom syntaxes](../developer-guide/syntaxes.md).
## Significant change

## Change of `overrides.extends` behavior
We deprecated [most of the rules that enforce stylistic conventions](../user-guide/rules.md#deprecated). You should remove these rules from your configuration object.

We changed the `overrides.extends` behavior to merge rather than replace, to make it consistent with the `overrides.plugins`.
We recommend:

- using a pretty printer, like [Prettier](https://prettier.io/), alongside Stylelint
- extending [our standard config](https://www.npmjs.com/package/stylelint-config-standard) in your configuration object
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Note] Opportunity to suggest our users adopt our standard config, if they haven't already.


Stylelint and pretty printers are complementary tools that work together to help you write consistent and error-free code. To help facilitate this, we've removed the [deprecated rules](../user-guide/rules.md#deprecated) from the latest version of [our standard config](https://www.npmjs.com/package/stylelint-config-standard). You can [extend](../user-guide/configure.md#extends) the config using:

```diff json
{
+ "extends": ["stylelint-config-standard"],
"rules" { .. }
}
```

[Our standard config](https://www.npmjs.com/package/stylelint-config-standard) turns on many of the [other rules that enforce conventions](../user-guide/rules.md#enforce-conventions), e.g. most of the [`*-notation`](../user-guide/rules.md#notation), [`*-pattern`](../user-guide/rules.md#pattern) and [`*-quotes`](../user-guide/rules.md#quotes) rules. We recommend adding more of [the rules that enforce conventions](../user-guide/rules.md#enforce-conventions) to your config as many of them will be specific to your needs, e.g. what [units you allow](../../lib/rules/unit-allowed-list/README.md) in your code.
Copy link
Member

@jeddy3 jeddy3 Dec 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Note] We originally positioned our standard config to be about formatting whitespace. It's changed significantly over time, especially now that we're deprecating the stylistic rules. This bit communicates that our standard config still offers plenty of value over our recommended config as it turns on a lot of rules that enforce conventions. Additionally, we recently regrouped how we list rules and this draws attention to that. All this is to inform our users that Stylelint is the best (and perhaps only) tool for enforcing non-stylistic conventions.

I suggest we mark the rules in our list that are included in our configs. This will help our users make use of the convention enforcing rules. Our current approach of listing rules in the config README isn't great as:

  • the list has fallen out of date
  • it's difficult to see the full picture of what rules are turned on and which aren't

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we mark the rules in our list that are included in our configs.

Sounds good. Do you already have an idea of how to realize it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you already have an idea of how to realize it?

I figured we could just whack an "R" and/or "S" on the end of the rule description and throw a key at the top. Something along the lines of:

(R & S) = In our recommended and standard configs
(S) = In our standard config

What do you think?

(We can do it in a follow-up pull request.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. It's the simplest solution, but there is a way to use emojis and a table for more readability. This is an example of eslint-plugin-react.

In addition, if we could add such information as R and S to each rule's metadata, it might be possible to check invalid documents or generate documents.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ⓡ and Ⓢ


For example, you can:

- [allow, disallow and require many things](../user-guide/rules.md#allowed-disallowed--required)
- [set limits on things like selectors](../user-guide/rules.md#max--min)

Additionally, you may no longer need to extend [Prettier's Stylelint config](https://www.npmjs.com/package/stylelint-config-prettier) as there should be no conflicting rules:

```diff json
{
- "extends": ["stylelint-config-prettier"],
"rules" { .. }
}
```

If you want to continue using Stylelint to enforce stylistic consistency, you can [migrate the deprecated rules you need to a plugin](../developer-guide/plugins.md). We will remove the rules from Stylelint in the next major release.
Copy link
Member

@jeddy3 jeddy3 Dec 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Note] This is at the bottom as it's not the recommended route. The rules are problematic and a plugin would suffer the same issues:

  • old code reliant on stylesearch
  • not cleanly working with the AST
  • introducing new lint problems
  • a confusing number of configuration options

Pretty printing an AST based on the line length is a better approach.


## Breaking changes

Three breaking changes may also affect you:

- removed support for Node.js 12
- removed support for processors
- changed `overrides.extends` behavior

## Removed support for Node.js 12

You should use the following or higher versions of Node.js:

- 14.13.1
- 16.0.0

### Removed support for processors

You should use a [custom syntax](../developer-guide/syntaxes.md)](../developer-guide/syntaxes.md) instead.

### Changed `overrides.extends` behavior

To be consistent with the `overrides.plugins`, `overrides.extends` will merge rather than replace.

If you would like to keep the previous behavior, you should change your config to:

Expand All @@ -25,10 +78,3 @@ If you would like to keep the previous behavior, you should change your config t
]
}
```

## Node.js 12

Support for Node.js 12 was dropped. You should use the following or higher versions of Node.js:

- 14.13.1
- 16.0.0
2 changes: 1 addition & 1 deletion docs/user-guide/configure.md
Expand Up @@ -184,7 +184,7 @@ You can _extend_ an existing configuration (whether your own or a third-party on
Popular configurations include:

- [stylelint-config-recommended](https://github.com/stylelint/stylelint-config-recommended) - turns on just the rules that [avoid errors](rules.md#avoid-errors)
- [stylelint-config-standard](https://github.com/stylelint/stylelint-config-standard) - extends recommended one by turning on rules that [enforce conventions](rules.md#enforce-non-stylistic-conventions)
- [stylelint-config-standard](https://github.com/stylelint/stylelint-config-standard) - extends recommended one by turning on rules that [enforce conventions](rules.md#enforce-conventions)

You'll find more in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#configs).

Expand Down
14 changes: 1 addition & 13 deletions docs/user-guide/get-started.md
Expand Up @@ -29,18 +29,6 @@ npx stylelint "**/*.css"

_You should include quotation marks around file globs._

If you use a pretty printer alongside Stylelint, you should turn off any conflicting rules. For example, you can use [Prettier's shared config](https://www.npmjs.com/package/stylelint-config-prettier) to do that:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Note] We don't need to suggest using the config anymore as the configs won't conflict.


```shell
npm install --save-dev stylelint-config-prettier
```

```json
{
"extends": ["stylelint-config-standard", "stylelint-config-prettier"]
}
```

## Linting everything else

You'll need to use a [custom syntax](usage/options.md#customsyntax) written by the community.
Expand Down Expand Up @@ -152,7 +140,7 @@ You can adapt your:
- [rules](configure.md#rules)
- [plugins](configure.md#plugins)

We recommend you add [more of the rules that enforce conventions](rules.md#enforce-non-stylistic-conventions) to your configuration, e.g. [`unit-allowed-list`](../../lib/rules/unit-allowed-list/README.md) and [`selector-max-id`](../../lib/rules/selector-max-id/README.md). These are powerful rules that you can use to enforce non-stylistic consistency in your code.
We recommend you add [more of the rules that enforce conventions](rules.md#enforce-conventions) to your configuration, e.g. [`unit-allowed-list`](../../lib/rules/unit-allowed-list/README.md) and [`selector-max-id`](../../lib/rules/selector-max-id/README.md). These are powerful rules that you can use to enforce non-stylistic consistency in your code.

You can add plugins written by the community to lint more things. For example, you may want to use the [stylelint-csstree-validator plugin](https://www.npmjs.com/package/stylelint-csstree-validator) to validate property and value pairs.

Expand Down