Contributing

Thank you for wanting to contribute.

To help out, you can:

• get involved in any open issue or pull request
• create, enhance and debug rules using our guide
• improve the documentation
• benchmark and improve performance
• open new issues about your ideas for making Stylelint 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 about what we could do better.

info

Create pull requests for issues opened by others only if the issue is labeled status: ready to implement.

Code contributions

To start coding, you'll need the:

• LTS release of Node.js
• latest npm

Then:

1. Fork and clone the Stylelint repository.
2. Install all the dependencies with npm ci.
3. Set up with npm run prepare.

tip

Stylelint's .npmrc is hardened against supply-chain risk. You should consider doing the same for your ~/.npmrc.

Run tests

Next, you'll want to run the tests using npm test. This runs all 10,000+ unit tests with the Node.js test runner.

During development, pass the files you're changing to npm run watch to run just their tests and rerun them whenever a file changes:

npm run watch -- lib/rules/unit-allowed-list/__tests__/index.mjs lib/rules/unit-disallowed-list/__tests__/index.mjs

Other node --test options pass through the same way.

Write code

With the tests running in watch mode, you can write code confident that things are working as expected.

You can write code to:

• add a rule
• add an option to a rule
• fix a bug in a rule
• improve the performance of a rule

If you plan to use a LLM to help you write the code, you can generate a local instructions file by pointing it at the codebase, especially the docs directory, and then locally git ignoring the file.

You should not use a LLM to fix issues labeled "good first issue" as these intended to be learning opportunities for new contributors.

Format and lint code

We use Prettier and ESLint (with a lint-staged precommit) to format and fix your code automatically.

You can also run:

• npm run format to format all the files
• npm run lint to check everything with Prettier, ESLint, remark and tsc

Open a pull request

When you have something to share, it's time to open a pull request.

Please take responsibility for any code or words written, especially if you used a LLM to help you. In return, we'll review your pull request and give you feedback.

info

Don't use a LLM to fill in templates or respond to review comments, unless it's purely to translate from your own language. It's not respectful of the reviewer's time.

You should:

• use and complete our pull request template
• give your pull request the same title as the corresponding issue because it becomes the commit message when we squash and merge
• apply any suggested changes (either individually or as a batch), rather than push your own commits, so that GitHub automatically resolves the corresponding note and assigns attibution

And should not:

• force-push after the review has started to help us keep track of changes
• request a review from an individual member, as any member can review the pull request when they have time

Once it's ready, we'll squash the commits and merge it.

Financial contributions

We welcome financial contributions in full transparency on our Open Collective or GitHub Sponsor.

Anyone can file an expense. We will "merge" the expense into the ledger if it makes sense for the development of the community. Open Collective then reimburses the person who filed the expense.

You can financially support us by becoming a backer or sponsor on Open Collective or a sponsor on GitHub.