Merge branch 'master' into browser-bundle

# By Richard Hallows (4) and others
# Via GitHub
* master:
  Create codeql analysis workflow (#4850)
  Update CHANGELOG.md
  Add support for descriptions in stylelint command comments (#4848)
  Update CHANGELOG.md
  Add *-allowed-list/*-disallowed-list/*-required-list names for *-whitelist/*-blacklist/*-requirelist rules (#4845)
  Update CHANGELOG.md
  Add syntax object acceptance to customSyntax option (#4839)
  Bump typescript from 3.9.5 to 3.9.6 (#4853)
  Add ignoreComments[] to comment-empty-line-before (#4841)
  Bump autoprefixer from 9.8.0 to 9.8.2 (#4838)

.github/workflows/code-scanning.yml

@@ -0,0 +1,50 @@
+name: 'Code Scanning'
+
+on:
+  push:
+  pull_request:
+  schedule:
+    - cron: '0 7 * * 1'
+
+jobs:
+  CodeQL:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v2
+        with:
+          # We must fetch at least the immediate parents so that if this is
+          # a pull request then we can checkout the head.
+          fetch-depth: 2
+
+      # If this run was triggered by a pull request event, then checkout
+      # the head of the pull request instead of the merge commit.
+      - run: git checkout HEAD^2
+        if: ${{ github.event_name == 'pull_request' }}
+
+      # Initializes the CodeQL tools for scanning.
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v1
+
+        # Override language selection by uncommenting this and choosing your languages
+        # with:
+        #   languages: go, javascript, csharp, python, cpp, java
+      # Autobuild attempts to build any compiled languages  (C/C++, C#, or Java).
+      # If this step fails, then you should remove it and run the build manually (see below)
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v1
+
+      # ℹ️ Command-line programs to run using the OS shell.
+      # 📚 https://git.io/JvXDl
+
+      # ✏️ If the Autobuild fails above, remove it and uncomment the following three lines
+      #    and modify them (or add more) to build your code if your project
+      #    uses a compiled language
+
+      #- run: |
+      #   make bootstrap
+      #   make release
+
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v1

.github/workflows/linting.yml

@@ -0,0 +1,41 @@
+name: Linting
+
+on:
+  push:
+    branches:
+      - master
+      - 'dependabot/**'
+  pull_request:
+    branches:
+      - '**'
+
+env:
+  CI: true
+
+jobs:
+  lint:
+    name: Lint on Node.js ${{ matrix.node }} and ${{ matrix.os }}
+
+    runs-on: ${{ matrix.os }}
+
+    strategy:
+      matrix:
+        node: [12]
+        os: [ubuntu-latest]
+
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Use Node.js ${{ matrix.node }}
+        uses: actions/setup-node@v1
+        with:
+          node-version: ${{ matrix.node }}
+
+      - name: Install latest npm
+        run: npm install --global npm@latest
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Lint
+        run: npm run pretest

.github/workflows/nodejs.yml → .github/workflows/testing.yml

@@ -1,4 +1,4 @@
-name: CI
+name: Testing
 
 on:
   push:
@@ -13,33 +13,6 @@ env:
   CI: true
 
 jobs:
-  lint:
-    name: Lint on Node.js ${{ matrix.node }} and ${{ matrix.os }}
-
-    runs-on: ${{ matrix.os }}
-
-    strategy:
-      matrix:
-        node: [12]
-        os: [ubuntu-latest]
-
-    steps:
-      - uses: actions/checkout@v2
-
-      - name: Use Node.js ${{ matrix.node }}
-        uses: actions/setup-node@v1
-        with:
-          node-version: ${{ matrix.node }}
-
-      - name: Install latest npm
-        run: npm install --global npm@latest
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Lint
-        run: npm run pretest
-
   test:
     name: Test on Node.js ${{ matrix.node }} and ${{ matrix.os }}
 

CHANGELOG.md

@@ -4,7 +4,11 @@ All notable changes to this project are documented in this file.
 
 ## Head
 
+- Added: syntax object acceptance to `customSyntax` option ([#4839](https://github.com/stylelint/stylelint/pull/4839)).
+- Added: support for descriptions in stylelint command comments ([#4848](https://github.com/stylelint/stylelint/pull/4848)).
+- Added: `*-allowed-list`, `*-disallowed-list` and `*-required-list` new names for `*-whitelist`, `*-blacklist` and `*-requirelist` rules, respectively; the rules are aliased as their old names ([#4845](https://github.com/stylelint/stylelint/pull/4845)).
 - Added: `ignoreContextFunctionalPseudoClasses` to `selector-max-id` ([#4835](https://github.com/stylelint/stylelint/pull/4835)).
+- Added: `ignoreComments[]` to `comment-empty-line-before` ([#4841](https://github.com/stylelint/stylelint/pull/4841)).
 
 ## 13.6.1
 

docs/maintainer-guide/issues.md

@@ -34,10 +34,10 @@ Rename the title into a consistent format.
 You should:
 
 - lead with the [CHANGELOG group names](pull-requests.md), but in the present tense:
-  - "Remove y", e.g. "Remove unit-blacklist"
+  - "Remove y", e.g. "Remove unit-disallowed-list"
   - "Deprecate x in y", e.g. "Deprecate resolvedNested option in selector-class-pattern"
-  - "Add y", e.g. "Add unit-blacklist"
-  - "Add x to y", e.g. "Add ignoreProperties: [] to property-blacklist"
+  - "Add y", e.g. "Add unit-disallowed-list"
+  - "Add x to y", e.g. "Add ignoreProperties: [] to property-disallowed-list"
   - "Fix false positives/negatives for x in y", e.g. "Fix false positives for Less mixins in color-no-hex"
 - use `*` if the issue applies to a group of rules, e.g. "Fix false negatives for SCSS variables in selector-\*-pattern"
 

docs/maintainer-guide/pull-requests.md

@@ -29,5 +29,5 @@ When merging a PR, you should:
    2. Prefix the item with either: "Removed", "Changed", "Deprecated", "Added", or "Fixed".
    3. Order the item within the group by the widest-reaching first to the smallest, and then alphabetically by rule name.
    4. Suffix the item with the relevant pull request number, using the complete GitHub URL so that it works on [the website](https://stylelint.io/CHANGELOG/).
-   5. If applicable, lead the item with the name of the rule, e.g. "Fixed: `unit-blacklist` false positives for SCSS nested properties".
+   5. If applicable, lead the item with the name of the rule, e.g. "Fixed: `unit-disallowed-list` false positives for SCSS nested properties".
 3. Post this update as a comment to the pull request.

docs/user-guide/configure.md

@@ -61,7 +61,7 @@ You can add any number of keys in the object. For example, you can:
 
 - turn off `block-no-empty`
 - turn on `comment-empty-line-before` with a primary and secondary option
-- turn on `max-empty-lines` and `unit-whitelist` with primary options
+- turn on `max-empty-lines` and `unit-allowed-list` with primary options
 
 ```json
 {
@@ -74,7 +74,7 @@ You can add any number of keys in the object. For example, you can:
       }
     ],
     "max-empty-lines": 2,
-    "unit-whitelist": ["em", "rem", "%", "s"]
+    "unit-allowed-list": ["em", "rem", "%", "s"]
   }
 }
 ```

docs/user-guide/get-started.md

@@ -43,7 +43,7 @@ To further customize your stylelint configuration, you can adapt your:
 - [shared configs](configure.md#extends)
 - [plugins](configure.md#plugins)
 
-We recommend you add [rules that limit language features](rules/list.md#limit-language-features) to your configuration, e.g. [`unit-whitelist`](../../lib/rules/unit-whitelist/README.md), [`selector-class-pattern`](../../lib/rules/selector-class-pattern/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 [rules that limit language features](rules/list.md#limit-language-features) to your configuration, e.g. [`unit-allowed-list`](../../lib/rules/unit-allowed-list/README.md), [`selector-class-pattern`](../../lib/rules/selector-class-pattern/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.
 
 ### Your usage
 

docs/user-guide/ignore-code.md

@@ -62,6 +62,16 @@ stylelint supports complex, overlapping disabling & enabling patterns:
 
 **Caveat:** Comments within _selector and value lists_ are currently ignored.
 
+You may also include a description at the end of the comment, after two hyphens:
+
+```css
+/* stylelint-disable -- Reason for disabling stylelint. */
+/* stylelint-disable foo -- Reason for disabling the foo rule. */
+/* stylelint-disable foo, bar -- Reason for disabling the foo and bar rules. */
+```
+
+**Important:** There must be a space on both sides of the hyphens.
+
 ## Files entirely
 
 You can use a `.stylelintignore` file to ignore specific files. For example:

docs/user-guide/rules/combine.md

@@ -275,33 +275,33 @@ You can do that with:
 }
 ```
 
-## `*-whitelist`, `*-blacklist`, `color-named` and applicable `*-no-*` rules
+## `*-allowed-list`, `*-disallowed-list`, `color-named` and applicable `*-no-*` rules
 
 These rules work together to (dis)allow language features and constructs.
 
-There are `*-whitelist` and `*-blacklist` rules that target the constructs of the CSS language: at-rules, functions, declarations (i.e. property-value pairs), properties and units. These rules (dis)allow any language features that make use of these constructs (e.g. `@media`, `rgb()`). However, there are features not caught by these `*-whitelist` and `*-blacklist` rules (or are, but would require complex regex to configure). There are individual rules, usually a `*-no-*` rule (e.g. `color-no-hex` and `selector-no-id`), to disallow each of these features.
+There are `*-allowed-list` and `*-disallowed-list` rules that target the constructs of the CSS language: at-rules, functions, declarations (i.e. property-value pairs), properties and units. These rules (dis)allow any language features that make use of these constructs (e.g. `@media`, `rgb()`). However, there are features not caught by these `*-allowed-list` and `*-disallowed-list` rules (or are, but would require complex regex to configure). There are individual rules, usually a `*-no-*` rule (e.g. `color-no-hex` and `selector-no-id`), to disallow each of these features.
 
-Say you want to disallow the `@debug` language extension. You can do that using either the `at-rule-blacklist` or `at-rule-whitelist` rules because the `@debug` language extension uses the at-rule construct e.g.
+Say you want to disallow the `@debug` language extension. You can do that using either the `at-rule-disallowed-list` or `at-rule-allowed-list` rules because the `@debug` language extension uses the at-rule construct e.g.
 
 ```json
 {
-  "at-rule-blacklist": ["debug"]
+  "at-rule-disallowed-list": ["debug"]
 }
 ```
 
 Say you want to, for whatever reason, disallow the whole at-rule construct. You can do that using:
 
 ```json
 {
-  "at-rule-whitelist": []
+  "at-rule-allowed-list": []
 }
 ```
 
-Say you want to disallow the value `none` for the `border` properties. You can do that using either the `declaration-property-value-blacklist` or `declaration-property-value-whitelist` e.g.
+Say you want to disallow the value `none` for the `border` properties. You can do that using either the `declaration-property-value-disallowed-list` or `declaration-property-value-allowed-list` e.g.
 
 ```json
 {
-  "declaration-property-value-blacklist": [
+  "declaration-property-value-disallowed-list": [
     {
       "/^border/": ["none"]
     }
@@ -311,7 +311,7 @@ Say you want to disallow the value `none` for the `border` properties. You can d
 
 ## `color-*` and `function-*` rules
 
-Most `<color>` values are _functions_. As such, they can be (dis)allowed using either the `function-blacklist` or `function-whitelist` rules. Two other color representations aren't functions: named colors and hex colors. There are two specific rules that (dis)allow these: `color-named` and `color-no-hex`, respectively.
+Most `<color>` values are _functions_. As such, they can be (dis)allowed using either the `function-allowed-list` or `function-disallowed-list` rules. Two other color representations aren't functions: named colors and hex colors. There are two specific rules that (dis)allow these: `color-named` and `color-no-hex`, respectively.
 
 Say you want to enforce using a named color _if one exists for your chosen color_ and use `hwb` color if one does not, e.g.:
 
@@ -323,23 +323,23 @@ a {
 }
 ```
 
-If you're taking a whitelisting approach, you can do that with:
+If you're taking an allow approach, you can do that with:
 
 ```json
 {
   "color-named": "always-where-possible",
   "color-no-hex": true,
-  "function-whitelist": ["hwb"]
+  "function-allowed-list": ["hwb"]
 }
 ```
 
-Or, if you're taking a blacklisting approach:
+Or, if you're taking a disallow approach:
 
 ```json
 {
   "color-named": "always-where-possible",
   "color-no-hex": true,
-  "function-blacklist": ["/^rgb/", "/^hsl/", "gray"]
+  "function-disallowed-list": ["/^rgb/", "/^hsl/", "gray"]
 }
 ```
 
@@ -349,12 +349,12 @@ This approach scales to when language extensions (that use the two built-in exte
 {
   "color-named": "never",
   "color-no-hex": true,
-  "function-whitelist": ["my-color"]
+  "function-allowed-list": ["my-color"]
 }
 ```
 
 ## Manage conflicts
 
-Each rule stands alone, so sometimes it's possible to configure rules such that they conflict with one another. For example, you could turn on two conflicting blacklist and whitelist rules, e.g. `unit-blacklist` and `unit-whitelist`.
+Each rule stands alone, so sometimes it's possible to configure rules such that they conflict with one another. For example, you could turn on two conflicting allow and disallow list rules, e.g. `unit-allowed-list` and `unit-disallowed-list`.
 
 It's your responsibility as the configuration author to resolve these conflicts.