stylelint

stylelint [options] ...
stylelint [options] --

--config
    Specify a configuration file. (e.g., --config .stylelintrc.json)

--fix
    Automatically fix a majority of stylistic warnings.

--format
    Specify the output formatter. (e.g., --format compact, stylish, json, string, unix, tap, verbose)

--ignore-path
    Specify a file to ignore patterns from. (e.g., --ignore-path .stylelintignore)

--ignore-pattern
    Specify a pattern of files to ignore. (e.g., --ignore-pattern "**/dist/**")

--syntax
    Specify a non-standard syntax to parse. (e.g., scss, less, sugarss, css-in-js)

--color, --no-color
    Force enabling or disabling of color output.

--version
    Output the stylelint version number.

--help
    Output usage information and available options.

--quiet
    Do not report warnings; only errors are shown.

--allow-empty-input
    Allow the file pattern to not match any files without error.

--max-warnings
    Set a limit for the number of warnings; exceeding it causes an exit with status code 2.

--stdin
    Accept input from stdin.

--stdin-filename
    Specify the filename to process stdin as, for proper rules application.

stylelint is a powerful and modern linter that helps you avoid errors and enforce consistent conventions in your stylesheets. It supports a wide range of CSS-like syntaxes, including CSS, SCSS, Less, and SugarSS, and is highly configurable with over 170 built-in rules. Developers can create custom rules and plugins, making it adaptable to almost any project's styling guidelines.

stylelint can be run from the command line, integrated into build processes, or used within IDEs, providing immediate feedback and contributing to higher code quality, maintainability, and collaboration across development teams. It's an essential tool for maintaining large and small frontend codebases by ensuring code consistency and catching potential issues early.

• Performance: For very large projects or extensive rule sets, stylelint can be resource-intensive, potentially slowing down build processes or pre-commit hooks.
• Configuration Complexity: Setting up and maintaining a comprehensive .stylelintrc configuration can be complex, especially with numerous custom rules and overrides for different file types.
• "Bikeshedding": Discussions around specific stylistic rules (e.g., single vs. double quotes, space before colon) can sometimes lead to unproductive debates among team members.
• False Positives: Occasionally, complex CSS or non-standard syntax might trigger false positives that require disabling rules for specific lines or files.

stylelint relies heavily on configuration files (e.g., .stylelintrc.json, .stylelintrc.js, or a stylelint field in package.json) to define rules, extend shared configurations, and specify processors. These files allow for granular control over linting behavior and enable projects to enforce unique coding standards tailored to specific requirements.

Beyond the command line, stylelint integrates seamlessly with various development environments. It can be set up with build tools like Webpack or Gulp, used as a PostCSS plugin, or provide real-time feedback through editor plugins for VS Code, Sublime Text, and Atom, making linting an integral part of the development workflow and instantly highlighting style violations.

stylelint emerged in the mid-2010s as a modern, extensible alternative to existing CSS linters, gaining rapid adoption within the frontend development community. It was designed from the ground up to be highly configurable, support a wide array of CSS-like syntaxes through PostCSS integration, and leverage a robust plugin ecosystem. Its focus on providing a clear AST for styling languages and its active community contributions have solidified its position as the de facto standard for CSS linting in contemporary web development, evolving to meet new language features and best practices.

eslint(1), prettier(1), semistandard(1), csslint