FAQ

Find answers to common questions about Ultracite, including setup, supported toolchains, editor integrations, and migration choices.

Q: What exactly is Ultracite, and how is it different from Oxlint, Biome, or ESLint?

Ultracite is essentially a preset configuration built on top of an existing toolchain. Think of Ultracite as a curated bundle of rules and settings, whereas the underlying engine — Biome, ESLint + Prettier + Stylelint, or Oxlint + Oxfmt — is what actually formats / lints code. You can use any of those tools by themselves, but you’d have to decide which rules to enable and configure their options manually. Ultracite saves you that effort by providing a ready-to-go setup that uses best practices from across the ecosystem.

Compared to ESLint + Prettier, Oxlint and Biome are faster thanks to their Rust implementations, and Biome is unified (one tool instead of two or three). If you already love tweaking every ESLint rule, Ultracite might feel restrictive; but it aims to eliminate the need for that and adopt sensible defaults.

In short: Oxlint / Biome / ESLint is the engine (linter / formatter), Ultracite is the configuration.

Q: Do I still need ESLint or Prettier if I use Ultracite?

It depends on which provider you choose. With the default Oxlint + Oxfmt provider (or the Biome provider), Ultracite replaces the functionality of ESLint and Prettier for your JavaScript / TypeScript code — you do not need to run them at all, and it’s recommended to remove those configs to avoid conflicts (init does this automatically). Ultracite’s output will cover most of the formatting and linting that those tools did, usually with equivalent or stricter rules.

If you prefer to stay in the ESLint ecosystem — for example, because you rely on a specialized ESLint plugin — you can choose Ultracite’s ESLint + Prettier + Stylelint provider instead, which gives you the same curated preset on top of those tools.

Q: What about my non-JS/TS files? Does Ultracite handle those?

It depends on the provider. With the default Oxlint + Oxfmt, Oxlint lints JavaScript and TypeScript (including JSX/TSX and the scripts in Vue, Svelte, and Astro files) and Oxfmt formats a much wider set, including JSON, CSS, SCSS, Less, HTML, Markdown, YAML, and GraphQL. Biome lints and formats JavaScript, TypeScript, JSON, CSS, GraphQL, and HTML. With ESLint, Prettier formats most file types and Stylelint lints CSS, SCSS, and Less. See the Languages page for a full breakdown per provider.

Q: How often is Ultracite updated?

Ultracite is updated as needed, often following the release cycles of Oxlint, Oxfmt, and Biome. Since those tools add rules frequently, you might see frequent minor releases to Ultracite. These updates can bring new rules, bug fixes, or adjustments to defaults. init doesn’t pin Ultracite to an exact version, so package.json typically records a ^x.y.z range. Your lockfile keeps installs reproducible, and you pick up new releases when you update dependencies or run npx ultracite upgrade.

It’s a good idea to watch the Ultracite repo for releases or check the Releases page. When updating Ultracite, read the release notes: occasionally a new rule is enabled that could surface new warnings in your project (which is a good thing for catching issues, but you should be aware of it).

Each release is verified against specific linter versions, and release notes state the minimum version required whenever that floor moves. To update Ultracite and your linter together, run npx ultracite upgrade — see Upgrading. npx ultracite doctor tells you if the two have drifted apart.

Q: If I disagree with a rule Ultracite enforces, what should I do?

You have a few options:

• Configure it off or to a different level in your linter config (oxlint.config.ts or .mts, biome.jsonc, or eslint.config.mjs) as a quick fix for your project. See Configuration.
• Open a discussion on the GitHub repo if the rule should be adjusted for everyone. The maintainers might agree it’s too strict or could be optional.
• If it’s a stylistic thing, remember the goal of Ultracite is to have convention over configuration: sometimes it’s worth adapting to the tool’s style for consistency across projects. But of course, your project’s needs come first.

Ultimately, you control your project’s lint config. Ultracite is a starting point; feel free to mold it, but ideally in minor ways. If you find yourself turning off a majority of rules, then Ultracite might not be the right preset for your team’s preferences (though that would be uncommon).

In that case, you could build your own linter config from scratch, but you’d lose a lot of the convenience. Usually, a few tweaks are all that’s needed to make Ultracite fit nicely.

Q: Can I use Ultracite without VS Code / Cursor / Windsurf?

Yes. We focus on VS Code and its forks as they’re the most popular IDEs for modern web development, but init can also write Zed settings (--editors zed), and every toolchain runs from the command line with ultracite check and ultracite fix, so it works in any editor or CI.

Oxlint, Biome, and ESLint each publish integrations for other editors. For Biome, see its first-party and third-party editor integrations.

Q: How do I know what rules Ultracite is enforcing? Is there a list?

Yes, check the Biome configs, Oxlint configs, and ESLint configs in the GitHub repo for the rules that are enabled. Each framework (React, Next.js, etc.) has its own preset that you add alongside core; framework presets don’t include the core rules themselves.

Q: Can Ultracite fix all issues it finds?

Not all, but many. Ultracite will auto-fix issues that are safe and deterministic to fix. These include formatting issues and many lint errors (particularly stylistic or simple code transformations like removing unused imports, adding missing parentheses, changing == to ===, etc.).

Some fixes are available but intentionally require --unsafe because they may change behavior. For example, Ultracite enables Biome’s noSubstr rule, but rewriting substring() or substr() to slice() only happens when you run ultracite fix --unsafe.

More complex issues (business logic or things that require developer intention) are left for you to fix. For example, it won’t magically rename variables to follow a naming convention or add missing error handling code; it will just warn you. For those, ultracite fix --claude or --codex can hand the remaining issues to an AI agent (see AI-Powered Fixing).

The philosophy is similar to ESLint’s: provide fixes where possible, but don’t risk altering code behavior. Always review the Problems panel or CLI output for any remaining warnings after auto-fix.

Q: Where can I learn more about the tools Ultracite uses?

Each toolchain has its own documentation: Oxlint and Oxfmt, Biome, and ESLint, Prettier, and Stylelint. If you’re curious about how your linter formats code or the philosophy behind certain choices, its docs are the best resource.

Understanding the underlying tool can help you better understand Ultracite’s capabilities. However, you don’t need to learn it in depth to use Ultracite effectively; Ultracite’s goal is to abstract those details away for most users.

Q: How do I disable Ultracite for a specific project or file?

If you have a project where you temporarily don’t want Ultracite, remove the Ultracite presets from your linter config (the ultracite/... imports in oxlint.config.ts and oxfmt.config.ts, or their .mts versions, the extends entries in biome.jsonc, or the imports in eslint.config.mjs), or remove the config files. If your editor’s linter extension is installed, it may still format on save using the tool’s defaults; to fully disable it, turn off formatOnSave or disable the extension for that workspace.

For a specific file, use your linter’s ignore comments (// oxlint-disable, // biome-ignore, or /* eslint-disable */) or add the file to its ignore patterns (ignorePatterns for Oxlint and Oxfmt, files.includes for Biome, ignores for ESLint). Essentially, Ultracite is opt-in per project via the config: if it’s not configured, it won’t run.

Q: I’m getting a corepack error during installation. What should I do?

Some users have encountered signature verification errors when running pnpm dlx ultracite init with corepack, particularly on Node.js v22 with older corepack versions. The error typically looks like “Cannot find matching keyid” during package installation.

Here are the recommended solutions:

• Update corepack: Upgrade to corepack version 0.34.0 or later. You can do this with corepack prepare pnpm@latest --activate or by following the pnpm corepack setup guide.
• Update Node.js: If you’re on Node.js v20.x, consider upgrading to v22 or later, which includes a more recent corepack version.
• Use npx instead: If corepack continues to cause issues, you can use npx ultracite init instead of pnpm dlx ultracite init.

If none of these work, please open an issue on the Ultracite GitHub repo with details about your Node.js and corepack versions.

We hope these FAQs clear up common points of confusion. If you have a question that isn’t answered here, feel free to reach out on the project’s GitHub or community channels. Ultracite is here to make your developer life easier, so feedback and questions are always welcome to help improve it!