This repository contains the source code and documentation for Base UI: a headless, unstyled React component library.
- Source code for components and private utils is in
packages/react/. - Source code for public shared utils is in
packages/utils/. - Experiments are located at
docs/src/app/(private)/experiments/. Use for creating demos that require manual testing in the browser. - Public documentation is located at
docs/src/app/(docs)/react/. Alter the docs where necessary when changes must be visible to library users. - When creating public demos on the docs, refer to the
herodemo for the given component and largely follow its styles (both CSS Modules and Tailwind CSS versions). Other demos may also contain relevant styling. Do not add custom styling beyond the critical layout styles necessary for new demos.
- Always use the
useTimeoututility from@base-ui/utils/useTimeoutinstead ofwindow.setTimeout, anduseAnimationFramefrom@base-ui/utils/useAnimationFrameinstead ofrequestAnimationFrame. Search for other example usage in the codebase if unsure how to use them. - Use the
useStableCallbackutility from@base-ui/utils/useStableCallbackinstead ofReact.useCallbackif the function is called within an effect or event handler. The utility cannot be used to memoize functions that are called directly in the body of a component (during render), so continue withReact.useCallbackin those scenarios. - Always use the
useIsoLayoutEffectutility from@base-ui/utils/useIsoLayoutEffectinstead ofReact.useLayoutEffect. - Always use the shadow DOM-safe utilities for DOM traversal and event targeting:
contains,getTarget, andactiveElement. Always use the owner utilitiesownerDocumentandownerWindowinstead of globaldocument/windowlookups when the code is tied to a DOM node, including realm-sensitive checks such asinstanceof. - Avoid duplicating logic where necessary. If two components can share logic (such as event handlers), define the logic/handlers in the parent and share it through a context to the child; use the existing context if it exists.
- Do not randomly cast (for example
as any) if there are no type errors without doing so. Runpnpm typescriptto verify types. - Ensure your changes pass linting - run
pnpm eslint. - Ensure your styles pass stylelint - run
pnpm stylelint. - Ensure your markdown passes markdownlint - run
pnpm markdownlint. - Ensure your changes are formatted correctly - run
pnpm prettier. - When you change a public component API (props or JSDoc), run
pnpm docs:api.
- If a repository command fails because dependencies are unavailable, run
pnpm ifirst and then retry the command. - Run tests in JSDOM env with
pnpm test:jsdom {name} --no-watchsuch aspnpm test:jsdom NumberField --no-watchorpnpm test:jsdom parse --no-watch. - Run tests in Chromium env with
pnpm test:chromium {name} --no-watchsuch aspnpm test:chromium NumberField --no-watchorpnpm test:jsdom parse --no-watch. - Do not call
await flushMicrotasks()directly afterawait render(...)when there are no interactions or state changes between them;renderis already awaited, so that immediate flush is unnecessary. - If you made changes to the source code, ensure you verify your changes by running tests (see above), and writing new tests where applicable. If tests require the browser because, for example, they require layout measurements, restrict it to the Chromium env by using
it.skipIf(isJSDOM)ordescribe.skipIf(isJSDOM)(search other tests for example usage if unsure). - Follow the established conventions in existing tests. Each file/component is tested with the filename
name.test.tsx. For example,PopoverRoot.test.tsxis next to its source filePopoverRoot.tsx. - Tests use Vitest APIs only:
expect(),vi.fn(), and@testing-library/jest-domDOM matchers. Do not use Chai- or Sinon-style matcher chains or spies.
- Commit messages follow the format
[scope] Imperative summary(for example[popover] Fix focus trap). Choose scopes that mirror package or component names that were changed. - Use
[all components]scope for changes that broadly affect most components.
These guidelines apply only to errors thrown by public packages.
Every error message must:
- Say what happened - Describe the problem clearly
- Say why it's a problem - Explain the consequence
- Point toward how to solve it - Give actionable guidance
Format:
- Prefix with
Base UI: - Use string concatenation for readability
- Include a documentation link when applicable (
https://base-ui.com/...)
You MUST run pnpm extract-error-codes to update docs/src/error-codes.json every time you add or update an error message in an Error constructor.
Important: If the update created a new error code, but the new and original message have the same number of arguments and semantics haven't changed, update the original error in error-codes.json instead of creating a new code.
Before any changes, review CONTRIBUTING.md for more detailed guidelines on contributing to this repository.