Contributing

Ultracite is an open-source project, and contributions are welcome! Whether you want to improve the documentation, adjust the configuration presets, or contribute code, here’s how you can get involved:

Source code

Ultracite’s source code is hosted on GitHub at haydenbleasel/ultracite. You can find all the configuration files, build scripts, and documentation in that repo. The project is primarily configuration (JSON and JavaScript for any CLI scaffolding). The repository also contains the docs.

Setting up locally

If you want to modify Ultracite or test changes:

1. Fork the repository on GitHub and clone it locally.
2. Run pnpm install (the project uses pnpm for managing dependencies and a lockfile, as indicated in the repo).
3. The config is in biome.json and related files. The CLI command (like ultracite init) likely has a script in the repo – check the package.json bin field or the scripts/ directory for implementation.
4. You can link your local Ultracite into a test project by using npm/yarn/pnpm link or npm pack to create a tarball and install it. This way, you can try your version of Ultracite on a sample project to see the effect of changes.
5. If you adjust rules in the config, test them by running npx biome lint or similar in the context of that config.

Project structure

Ultracite is mostly a wrapper around Biome’s config. You’ll find that it may simply extend Biome’s internal rule sets. The root biome.json contains the rules Ultracite enables / disabled. Editing those and testing their impact is the main way to change Ultracite’s behavior.

Editing the docs

If you want to contribute to documentation (like this site content), the repository has a docs folder that contains a Fumadocs app. To run it locally, run the following commands:

cd docs
pnpm install
pnpm run dev

This will start the Fumadocs app on http://localhost:3000.

Testing changes

If you add or remove rules, try running Ultracite on various sample codes to ensure there are no unexpected side effects. For instance, if you decide to enable a new rule by default, consider whether it might flag a lot of false positives. Running the config against a real project (or multiple) is a good idea. The repository might include some tests or fixtures – look for a test directory.

Opening pull requests

Typically if you want to add a new rule or change how a rule works internally, you should contribute to Biome's repository. If you want to adjust which rules are enabled or their default severity, you should make a change in Ultracite's repository.

Once Biome releases a version with the new rule, Ultracite can bump the Biome dependency and incorporate that rule (likely enabling it if it fits the strict preset).

If you're going to make a change to Ultracite, you should:

• Write clear commit messages and pull request descriptions.
• If you’re changing default behaviors, explain the rationale (e.g., “Rule X is causing too many false positives, turning it off by default” or “Adding support for Y framework”).
• Keep consistency with the coding style of the project.
• If adding a new config option, ensure it’s documented.

Building and versioning

Ultracite uses Intuit Auto to manage the release process and handle versioning. When a PR is merged, the release process will run and a new version will be published to npm. The type of release is handled by Auto based on the PR labels, which a maintainer will add.

Community discussions

If you encounter a bug, feel free to open a GitHub issue. Please be clear and provide examples.

If you want to discuss a potential change or feature request (e.g., “Ultracite should have an option to…”, or “Rule X is too strict…”), feel free to open a discussion.