stylelint-config-standard: Install and Tailor the Rules

Why stylelint-config-standard Exists

stylelint-config-standard is a shareable configuration rather than a standalone CSS parser or command-line linter. Its job is to supply a coherent set of Stylelint rules so a project does not have to select and tune those rules independently. The repository describes it as the standard shareable config for Stylelint and identifies Stylelint as its intended ecosystem.

The configuration targets modern CSS. It extends `stylelint-config-recommended` and enables additional rules associated with current CSS specifications and features within Baseline Widely Available. That distinction matters because this package is stricter than a bare recommended baseline. It is intended for teams that want conventions beyond merely identifying questionable or invalid patterns, provided those conventions fit their stylesheets.

The intended users are developers and teams already using Stylelint, especially JavaScript projects with an npm-based development setup. This is not a complete CSS quality system by itself. The README explicitly says that some Stylelint rules need configuration for project-specific needs, so adopters still have to decide which additional rules apply to their code.

How the Extended Stylelint Configuration Flows

The package has a deliberately small published surface. Its `package.json` exports the root entry as `./index.js`, and its `files` array contains only `index.js`. The README directs readers to that file for the exact rule list, which means the implementation, rather than the prose example, is the authoritative inventory.

The layering is straightforward. A consumer configuration names `stylelint-config-standard` through Stylelint's `extends` mechanism. That package then extends `stylelint-config-recommended`, declared as the runtime dependency `stylelint-config-recommended` at `^18.0.0`, before applying its additional standard rules. Stylelint resolves this configuration chain when linting, so consumers do not copy the complete rule list into their own project.

This arrangement separates a reusable baseline from local policy. Rules that require organizational knowledge remain configurable in the consumer. The README demonstrates disabling `selector-class-pattern`, reducing `property-no-vendor-prefix` to warning severity, and adding `unit-allowed-list`. Those examples also expose a practical constraint: a shareable config can establish a default, but it cannot know whether a particular naming pattern, physical unit, or severity matches a codebase.

Installing and Enabling stylelint-config-standard

Install the config as a development dependency so it accompanies the local toolchain rather than the package published to consumers.

npm install stylelint-config-standard --save-dev

Add the package name to the project's Stylelint configuration. This `extends` entry tells Stylelint to load the shareable rules.

{
  "extends": "stylelint-config-standard"
}

The package requires `stylelint` at `^17.0.0` as a peer dependency. The repository also requires Node.js `>=20.19.0`, so a first use should begin by checking the project's runtime and Stylelint versions. The package itself does not document a separate initialization command or custom server, because it is configuration consumed by Stylelint.

A useful first review is to lint the project with its existing Stylelint invocation and inspect reports rather than assuming every inherited rule matches the codebase. The README does not provide a package-specific lint command because this repository is the config package, not an application with source CSS to lint.

Overriding Rules for a Specific Codebase

Local overrides follow the standard Stylelint configuration model. Use `null` to turn off an inherited rule. This example accepts class names outside the shared `selector-class-pattern` rule.

{
  "extends": "stylelint-config-standard",
  "rules": {
    "selector-class-pattern": null
  }
}

Stylelint's secondary options can change severity without disabling the rule. Here, `property-no-vendor-prefix` remains enabled but reports warnings.

{
  "extends": "stylelint-config-standard",
  "rules": {
    "property-no-vendor-prefix": [
      true,
      {
        "severity": "warning"
      }
    ]
  }
}

A project can also add a rule that needs local values. The README uses `unit-allowed-list` to restrict accepted units to `em`, `rem`, and `s`.

{
  "extends": "stylelint-config-standard",
  "rules": {
    "unit-allowed-list": ["em", "rem", "s"]
  }
}

These are policy decisions, not compatibility shims. Disabling a rule is appropriate when the inherited convention does not fit the project. Adding a configured rule is appropriate when the team has a concrete requirement. The README does not document an automatic migration or rollback procedure for rule changes.

Modern CSS Scope and Compatibility Limits

The README's example is intentionally not a minimal stylesheet. It includes `@layer`, `@scope`, nested selectors, `light-dark()`, relative color syntax, container queries, `:has()`, logical properties, and other modern constructs. The note says the config is tested against this example because it contains plenty of modern CSS syntax and features. That supports the package's modern orientation, but it does not mean every browser, build pipeline, or parser in a consumer's toolchain supports those constructs.

This is the principal adoption risk. A stylesheet can pass this configuration's expectations while still depending on browser support that a project has not established. Conversely, an older codebase can generate substantial work simply by inheriting the additional rules. The package does not claim to solve CSS transpilation, browser support detection, or gradual adoption planning.

The config is also a preset, not a universal house style. It cannot resolve disagreements about naming conventions, permitted units, acceptable vendor prefixes, or whether warnings should fail a build. The README explicitly recommends adding more Stylelint rules that need configuration for specific needs. Projects with a mature internal CSS policy may prefer fewer changes when adopting a shared standard.

Maintenance, Releases, and the MIT Package Boundary

The repository is not archived, and the last push was on 2026-10-12. That is a maintenance fact, not proof that every rule will fit a given project. The listed releases include version 40.0.0 from 2026-01-15, preceded by 39.0.1 from 2025-10-06 and 39.0.0 from 2025-07-29. The current package version in `package.json` is 40.0.0.

Upgrade cost is tied to Stylelint compatibility and rule-policy changes. Version 40 depends on `stylelint-config-recommended` through `^18.0.0` and declares Stylelint `^17.0.0` as its peer dependency. Node.js must be at least 20.19.0. Consumers therefore need to review both their Node.js baseline and their Stylelint version before changing the config version.

The repository includes `CHANGELOG.md`, but the README only links to it and does not enumerate upgrade steps. It also does not document a rollback command. The package is published under the MIT license. That identifies the stated licensing model, but organizations should review the actual `LICENSE` file and dependency terms for their own compliance process.

Comparing the Standard Config with the Recommended Baseline

The closest documented alternative is `stylelint-config-recommended`. The difference is not two unrelated tools. `stylelint-config-standard` extends `stylelint-config-recommended` and adds further rules for conventions found in modern CSS specifications and Baseline Widely Available features.

Choose the recommended configuration when the project wants the narrower inherited baseline and prefers to select additional rules itself. Choose `stylelint-config-standard` when a shared opinionated default reduces configuration work and the team accepts its modern CSS policy. The standard config still supports local overrides, so choosing it does not require accepting every rule permanently.

A project with an established CSS policy may find direct use of `stylelint-config-recommended` easier to reconcile. A project beginning with standard modern CSS conventions gets more policy from `stylelint-config-standard`. The repository does not provide a rule-by-rule comparison between the two packages in its README, so the exact added inventory must be checked in `index.js` and the linked `stylelint-config-recommended` source.

Editorial conclusion

Adopt stylelint-config-standard when a Stylelint 17 project needs a maintained opinionated CSS baseline and the team can accept modern CSS conventions. Do not adopt it unchanged when its defaults conflict with a legacy stylesheet or an organization-specific policy. Before upgrading, verify the Node.js version, confirm compatibility with Stylelint 17, and run the existing lint suite against the CSS that is most likely to trigger rule changes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. stylelint/stylelint-config-standard on GitHub