Merge pull request #6618 from stylelint/v15

Prepare 15.0.0

.changeset/early-penguins-know.md

@@ -0,0 +1,5 @@
+---
+"stylelint": major
+---
+
+Changed: type names to be more consistent

.changeset/empty-goats-count.md

@@ -0,0 +1,5 @@
+---
+"stylelint": patch
+---
+
+Fixed: `property-no-unknown` false negatives for newer custom syntaxes

.changeset/few-monkeys-fold.md

@@ -0,0 +1,5 @@
+---
+"stylelint": minor
+---
+
+Added: `media-feature-name-unit-allowed-list` rule

.changeset/gold-llamas-pump.md

@@ -0,0 +1,5 @@
+---
+"stylelint": minor
+---
+
+Added: deprecated rule warnings

.changeset/great-queens-peel.md

@@ -0,0 +1,5 @@
+---
+"stylelint": major
+---
+
+Removed: Node.js 12 support

.changeset/grumpy-scissors-watch.md

@@ -0,0 +1,5 @@
+---
+"stylelint": major
+---
+
+Changed: `extends` in `overrides` to merge to be consistent with `plugins` behaviour

.changeset/hot-gifts-compete.md

@@ -0,0 +1,5 @@
+---
+"stylelint": major
+---
+
+Removed: support for processors

.changeset/nervous-insects-design.md

@@ -0,0 +1,5 @@
+---
+"stylelint": major
+---
+
+Removed: `syntax` option

.changeset/quiet-adults-leave.md

@@ -0,0 +1,5 @@
+---
+"stylelint": patch
+---
+
+Fixed: `function-no-unknown` false positives for interpolation and backticks in CSS-in-JS

.changeset/red-coins-rescue.md

@@ -0,0 +1,5 @@
+---
+"stylelint": minor
+---
+
+Deprecated: stylistic rules handled by Prettier

.changeset/sharp-papayas-grab.md

@@ -0,0 +1,5 @@
+---
+"stylelint": major
+---
+
+Changed: type definitions to reorganize

.github/workflows/code-scanning.yml

@@ -5,6 +5,7 @@ on:
     branches:
       - main
       - '!dependabot/**'
+      - v15 # TODO: We can remove this line after shipping v15.
   pull_request:
     # The branches below must be a subset of the branches above
     branches:

.github/workflows/releasing.yml

@@ -4,6 +4,7 @@ on:
   push:
     branches:
       - main
+      - v15 # TODO: We can remove this line after shipping v15.
 
 permissions:
   contents: write
@@ -39,8 +40,8 @@ jobs:
       - name: Create release pull request
         uses: changesets/action@v1
         with:
-          commit: Prepare release
-          title: Prepare release
+          commit: Prepare release 15.0.0
+          title: Prepare release 15.0.0
           # this expects you to have a npm script called version that runs some logic and then calls `changeset version`.
           # We're also restoring `package.json` because we're using `np` for publishing
           version: npm run version

.github/workflows/testing.yml

@@ -4,6 +4,7 @@ on:
   push:
     branches:
       - main
+      - v15 # TODO: We can remove this line after shipping v15.
   pull_request:
     branches:
       - '**'
@@ -25,7 +26,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        node: [12, 14, 16, 18]
+        node: [14, 16, 18]
         os: [ubuntu-latest, windows-latest, macos-latest]
 
     steps:
@@ -46,14 +47,14 @@ jobs:
 
       - name: Test
         run: npm run jest
-        if: "!(startsWith(matrix.os, 'ubuntu') && matrix.node == 16)"
+        if: "!(startsWith(matrix.os, 'ubuntu') && matrix.node == 18)"
 
       - name: Test with coverage
         run: npm run jest -- --coverage
-        if: startsWith(matrix.os, 'ubuntu') && matrix.node == 16
+        if: startsWith(matrix.os, 'ubuntu') && matrix.node == 18
 
       - name: Upload coverage to Codecov
         uses: codecov/codecov-action@v3
-        if: startsWith(matrix.os, 'ubuntu') && matrix.node == 16
+        if: startsWith(matrix.os, 'ubuntu') && matrix.node == 18
         with:
           files: ./.coverage/lcov.info

CHANGELOG.md

@@ -1179,7 +1179,7 @@ Changes:
 
 ## 7.0.0
 
-- Removed: `--extract` and `extractStyleTagsFromHtml` options. Instead, [build](/docs/developer-guide/processors.md) and [use](/docs/user-guide/configure.md#processors) processors.
+- Removed: `--extract` and `extractStyleTagsFromHtml` options. Instead, build and use processors.
 - Removed: support for plugin rule names that aren't namespaced, i.e. only `your-namespace/your-rule-name` rule names are supported. (If your plugin provides only a single rule or you can't think of a good namespace, you can simply use `plugin/my-rule`.)
 - Removed: `--verbose` CLI flag. Use `--formatter verbose` instead.
 - Removed: NodeJS `0.12.x` support. `4.2.1 LTS` or greater is now required.

CONTRIBUTING.md

@@ -5,15 +5,13 @@ Thank you for wanting to contribute.
 To help out, you can:
 
 - get involved in any open [issue](https://github.com/stylelint/stylelint/issues) or [pull request](https://github.com/stylelint/stylelint/pulls)
-- maintain [community custom syntaxes](docs/developer-guide/syntaxes.md)
 - create, enhance and debug rules using [our guide](docs/developer-guide/rules.md)
 - improve the [documentation](docs/)
 - add [new tests](https://github.com/stylelint/stylelint/issues?q=is%3Aopen+is%3Aissue+label%3A%22type%3A+tests%22) to _absolutely anything_
 - improve the [performance of rules](docs/developer-guide/rules.md#improve-the-performance-of-a-rule)
 - open [new issues](https://github.com/stylelint/stylelint/issues/new/choose) about your ideas for making Stylelint better
-- create or contribute to [integrations](docs/user-guide/integrations/editor.md), like our plugin for [VS Code](https://github.com/stylelint/vscode-stylelint)
 
-Not only will you help Stylelint thrive, but you may learn a thing or two — about CSS, PostCSS, Node, ES2015, unit testing, open-source software, and more. We want to encourage contributions! If you want to participate but couldn't, please [give us feedback](https://github.com/stylelint/stylelint/issues/new) about what we could do better.
+Not only will you help Stylelint thrive, but you may learn a thing or two — about CSS, PostCSS, Node.js, unit testing, open-source software, and more. We want to encourage contributions! If you want to participate but couldn't, please [give us feedback](https://github.com/stylelint/stylelint/issues/new) about what we could do better.
 
 ## Code contributions
 
@@ -25,7 +23,7 @@ To start coding, you'll need the:
 Then:
 
 1. [Fork and clone](https://guides.github.com/activities/forking/) the Stylelint repository.
-2. Install all the dependencies with `npm ci`.
+2. Install all the dependencies with `npm install`.
 
 ### Run tests
 
@@ -52,8 +50,6 @@ You can write code to:
 - [fix a bug in a rule](docs/developer-guide/rules.md#fix-a-bug-in-a-rule)
 - [improve the performance of a rule](docs/developer-guide/rules.md#improve-the-performance-of-a-rule)
 
-And many more things, including [writing system tests](docs/developer-guide/system-tests.md) and improving the [documentation](docs/).
-
 ### Format code
 
 We use [Prettier](https://prettier.io/) (with [a Husky and lint-staged precommit](https://prettier.io/docs/en/precommit.html)) to format your code automatically.

README.md

@@ -4,42 +4,41 @@
 [![Build Status](https://github.com/stylelint/stylelint/workflows/Testing/badge.svg)](https://github.com/stylelint/stylelint/actions/workflows/testing.yml?query=branch%3Amain)
 [![npm downloads](https://img.shields.io/npm/dm/stylelint)](https://npmcharts.com/compare/stylelint?minimal=true)
 
-A mighty, modern linter that helps you avoid errors and enforce conventions in your styles.
+A mighty CSS linter that helps you avoid errors and enforce conventions.
 
 ## Features
 
 It's mighty as it:
 
-- has over **170 built-in rules** for modern CSS syntax and features
-- supports **plugins** so you can create your own rules
+- has over **100 built-in rules** for modern CSS syntax and features
+- supports **plugins** so you can create your own custom rules
 - automatically **fixes problems** where possible
-- is **well tested** with over 15000 unit tests
-- supports **shareable configs** that you can extend or create
-- is **unopinionated** so that you can customize it to your exact needs
-- **complements pretty printers** like Prettier
-- has a **growing community** and is used by Google, GitHub and WordPress
+- supports **shareable configs** that you can create or extend
+- can **be customized** to your exact needs
+- has **15k unit tests** making it robust
+- is **trusted by companies worldwide** like Google and GitHub
 
-And can be extended to:
+And it can be extended to:
 
-- parse **CSS-like syntaxes** like SCSS, Sass, Less and SugarSS
-- extract **embedded styles** from HTML, Markdown and CSS-in-JS object & template literals
+- extract **embedded styles** from HTML, Markdown and CSS-in-JS template literals
+- parse **CSS-like languages** like SCSS, Sass, Less and SugarSS
 
 ## How it'll help you
 
 It'll help you **avoid errors**, for example:
 
-- invalid things, e.g. malformed hex colors and named grid areas
-- 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
+- invalid things, e.g. malformed grid areas
+- valid things that are problematic, e.g. duplicate selectors
+- unknown things, e.g. misspelled property names
 
-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
+- disallow things, e.g. specific units
+- enforce naming patterns, e.g. for custom properties
+- set limits, e.g. the number of ID selectors
+- specify notations, e.g. for modern color functions
 
-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 a pretty printer like Prettier alongside Stylelint. Linters and pretty printers are complementary tools that work together to help you write consistent and error-free code.
 
 ## Example output
 
@@ -49,29 +48,23 @@ There are also rules for enforcing stylistic conventions, but we now recommend y
 
 - User guide
   - [Getting started](docs/user-guide/get-started.md)
-  - [Configuration](docs/user-guide/configure.md)
+  - [Customizing](docs/user-guide/customize.md)
+  - [Configuring](docs/user-guide/configure.md)
   - [Rules](docs/user-guide/rules.md)
-  - Usage
-    - [CLI](docs/user-guide/usage/cli.md)
-    - [Node.js API](docs/user-guide/usage/node-api.md)
-    - [PostCSS plugin](docs/user-guide/usage/postcss-plugin.md)
-    - [Options](docs/user-guide/usage/options.md)
-  - Integrations
-    - [Editor integrations](docs/user-guide/integrations/editor.md)
-    - [Task runner integrations](docs/user-guide/integrations/task-runner.md)
-    - [Other integrations](docs/user-guide/integrations/other.md)
   - [Ignoring code](docs/user-guide/ignore-code.md)
-  - [Combining rules](docs/user-guide/combine.md)
-  - [Using regex](docs/user-guide/regex.md)
+  - [CLI](docs/user-guide/cli.md)
+  - [Node.js API](docs/user-guide/node-api.md)
+  - [PostCSS plugin](docs/user-guide/postcss-plugin.md)
+  - [Options](docs/user-guide/options.md)
   - [Errors & warnings](docs/user-guide/errors.md)
 - Developer guide
-  - [Working on rules](docs/developer-guide/rules.md)
+  - [Writing rules](docs/developer-guide/rules.md)
   - [Writing plugins](docs/developer-guide/plugins.md)
   - [Writing custom syntaxes](docs/developer-guide/syntaxes.md)
   - [Writing custom formatters](docs/developer-guide/formatters.md)
   - [Writing system tests](docs/developer-guide/system-tests.md)
-  - [Writing processors](docs/developer-guide/processors.md)
 - Migration guide
+  - [Migrating to 15.0.0](docs/migration-guide/to-15.md)
   - [Migrating to 14.0.0](docs/migration-guide/to-14.md)
 - Maintainer guide
   - [Managing issues](docs/maintainer-guide/issues.md)

SUPPORT.md

@@ -4,14 +4,12 @@ One of our frequently visited documentation sections might answer your query:
 
 - [Turning off rules](docs/user-guide/configure.md#rules)
 - [Ignoring code](docs/user-guide/ignore-code.md)
-- [Using regexes to configure rules](docs/user-guide/regex.md)
-- [Combining rules to enforce your code style](docs/user-guide/combine.md)
 
 If they don't, then post your query on [Stack Overflow](https://stackoverflow.com/questions/tagged/stylelint).
 
-Only create a [new issue](https://github.com/stylelint/stylelint/issues/new/choose) if:
+Only create a [new issue](https://github.com/stylelint/stylelint/issues/new/choose) if you:
 
-- you think you've found a bug
-- you have a feature request
+- think you've found a bug
+- have a feature request
 
 If you're upgrading, read our [CHANGELOG](CHANGELOG.md) to learn what changes to expect in the latest version.

docs/about/vision.md

@@ -4,8 +4,8 @@ A linter and validator for CSS that is:
 
 - complete - coverage of all standard CSS syntax
 - extensible - multiple points of extension
-- configurable - no defaults and options to tailor the linter
-- robust - comprehensive test coverage and a wide range of fixtures
+- configurable - options to tailor the linter
+- robust - comprehensive test coverage
 - consistent - conventions for behavior, naming and documentation
 - performant - tools to test and improve performance
 
@@ -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
 
@@ -23,7 +23,7 @@ Provide multiple points of extensions, including:
 - [custom syntaxes](../developer-guide/syntaxes.md) - use any PostCSS-compatible syntax to support other CSS-like languages and containers
 - [extendable configs](../user-guide/configure.md#extends) - extend and share configurations
 - [formatters](../developer-guide/formatters.md) - format Stylelint result objects
-- [plugins](../developer-guide/plugins.md) - build community rules to support methodologies, toolsets, non-standard CSS features, other languages (like SCSS) or very specific use cases
+- [plugins](../developer-guide/plugins.md) - build custom rules to support methodologies, toolsets, non-standard CSS features, other languages (like SCSS) or very specific use cases
 
 ## Robust
 

docs/developer-guide/plugins.md

@@ -1,8 +1,8 @@
 # Writing plugins
 
-Plugins are rules and sets of rules built by the community. They might support a particular methodology or toolset, or apply to non-standard constructs and features, or be for specific use cases.
+Plugins are custom rules and sets of custom rules. They might support a particular methodology or toolset, apply to non-standard constructs and features, or be for specific use cases.
 
-We recommend your plugin adheres to [Stylelint's conventions](rules.md) for:
+We recommend your custom rules adhere to our [rule conventions](rules.md) for:
 
 - names
 - options
@@ -210,7 +210,7 @@ it("doesn't warn for fileless sources", async () => {
 });
 ```
 
-Alternatively, if you don't want to use Jest you'll find more tools in [awesome stylelint](https://github.com/stylelint/awesome-stylelint#tools).
+Alternatively, if you don't want to use Jest you'll find more testing tool in [Awesome Stylelint](https://github.com/stylelint/awesome-stylelint#readme).
 
 ## `stylelint.utils`
 
@@ -288,7 +288,7 @@ All of the rule functions are available at `stylelint.rules`. This allows you to
 
 A typical use-case is to build in more complex conditionals that the rule's options allow for. For example, maybe your codebase uses special comment directives to customize rule options for specific stylesheets. You could build a plugin that checks those directives and then runs the appropriate rules with the right options (or doesn't run them at all).
 
-All rules share a common signature. They are a function that accepts two arguments: a primary option and a secondary options object. And that functions returns a function that has the signature of a PostCSS plugin, expecting a PostCSS root and result as its arguments.
+All rules share a common signature. They are a function that accepts two arguments: a primary option and a secondary options object. And that function returns a function that has the signature of a PostCSS plugin, expecting a PostCSS root and result as its arguments.
 
 Here's an example of a plugin that runs `declaration-no-important` only if there is a special directive `@@check-declaration-no-important` somewhere in the stylesheet:
 
@@ -317,18 +317,18 @@ In addition to the standard parsers mentioned in the ["Working on rules"](rules.
 
 - [postcss-resolve-nested-selector](https://github.com/davidtheclark/postcss-resolve-nested-selector): given a (nested) selector in a PostCSS AST, return an array of resolved selectors.
 
-Have a look through [Stylelint's internal utils](https://github.com/stylelint/stylelint/tree/main/lib/utils) and if you come across one that you need in your plugin, then please consider helping us extract it out into an external module.
+Have a look through [Stylelint's internal utils](https://github.com/stylelint/stylelint/tree/main/lib/utils) and if you come across one that you need in your plugin, then please consider helping us extract it into an external module.
 
 ## Peer dependencies
 
 You should express, within the `peerDependencies` key (and **not** within the `dependencies` key) of your plugin's `package.json`, what version(s) of Stylelint your plugin can be used with. This is to ensure that different versions of Stylelint are not unexpectedly installed.
 
-For example, to express that your plugin can be used with Stylelint versions 7 and 8:
+For example, to express that your plugin can be used with Stylelint versions 14 and 15:
 
 ```json
 {
   "peerDependencies": {
-    "stylelint": "^7.0.0 || ^8.0.0"
+    "stylelint": "^14.0.0 || ^15.0.0"
   }
 }
 ```