Start
Every release-candidate install should still use @next or pin the exact RC version — see the release status above.
Install the package boundary
Section titled “Install the package boundary”For an application that will consume BeeUI as packages:
npm install @beemvp/beeui-ui@next @beemvp/beeui-core@next @beemvp/beeui-tokens@nextThe CLI is published separately in the same lockstep release:
npx @beemvp/beeui-cli@next --helpPin @0.86.2-rc.3 instead of @next when you need an immutable prerelease version in CI or a reproducible consumer fixture.
Which intent is yours
Section titled “Which intent is yours”| Intent | You want to | Start at |
|---|---|---|
| Integrate the public RC | Install BeeUI into an Expo, bare React Native or Web app | Pick a platform |
| Evaluate the repository | See Showcase, demo, source and verification evidence together | Evaluate from source |
| Own component source | Copy selected BeeUI source into your repository and maintain it there | CLI & source ownership |
Prerequisites
Section titled “Prerequisites”BeeUI documents tested points, not unlimited compatibility promises. The authoritative machine-checked table lives in Compatibility.
| Requirement | Tested value | Needed for |
|---|---|---|
| Node.js | 24.13.1 |
repository tooling and verified consumers |
| pnpm | 10.15.0 |
repository commands |
| React / React DOM | 19.2.3 |
supported consumer paths |
| React Native | 0.86.2 |
Expo, bare React Native, Web via React Native Web |
| Expo SDK | ~57.0.0 |
Expo path |
react-native-web |
0.21.0 |
Web path |
| Tailwind CSS / Uniwind | 4.3.3 / 1.10.1 |
styling entry |
Check Compatibility for peer ranges and optional native peers before changing versions.
Versioning policy
Section titled “Versioning policy”The published npm version, the repository’s package.json version, and the React Native version it pins are all 0.86.x today, and that is a deliberate but coincidental alignment, not a rule: BeeUI’s package version tracks its own release history (prereleases are 0.86.2-rc.N; the stable release is 0.86.2), independently of whichever React Native version happens to share the same number. Do not assume BeeUI’s version implies a specific React Native version or vice versa — always check Compatibility for the actual pinned/tested peer versions. See docs/dist-tag-policy.md for the release/dist-tag mechanics.
Pick a platform
Section titled “Pick a platform”| Platform | Guide | Maintained executable authority | Evidence |
|---|---|---|---|
| Expo | Expo | examples/expo-package-consumer |
Metro export for Android, iOS and Web |
| Bare React Native | Bare React Native | examples/bare-rn-consumer |
Metro bundles plus native compile coverage in CI |
| Web | Web | examples/web-consumer |
production Web build |
The maintained consumer examples remain valuable even after public publication: they prove the exact package boundary in clean projects and catch deep imports, peer drift and bundler-resolution problems.
Already on 0.86.2-rc.1? See Upgrading from 0.86.2-rc.1 for the required Sheet provider rewiring and the other rc.2 changes before you update.
Evaluate from source
Section titled “Evaluate from source”Use the repository when you want the complete Showcase, demo and release evidence rather than only package consumption:
corepack enablepnpm install --frozen-lockfilepnpm build
pnpm showcasepnpm docs:buildpnpm --filter @beemvp/beeui-demo webRepository-local packed tarballs are still used by CI and can be useful for testing an unreleased commit, but they are no longer required to consume the published RC.
Two consumption models
Section titled “Two consumption models”Package boundary
Section titled “Package boundary”Choose packages when you want BeeUI upgrades to remain centralized behind package exports.
npm install @beemvp/beeui-ui@next @beemvp/beeui-core@next @beemvp/beeui-tokens@nextUse package subpaths documented by the generated component reference; do not deep-import unpublished internal files.
Source ownership
Section titled “Source ownership”Choose source ownership when you want selected BeeUI component source committed into your own repository, reviewed there and intentionally modified there.
npx @beemvp/beeui-cli@next listnpx @beemvp/beeui-cli@next add --dry-run buttonnpx @beemvp/beeui-cli@next add buttonnpx @beemvp/beeui-cli@next doctorSee CLI & source ownership and Registry for the ownership/update contract.
First BeeUI shell
Section titled “First BeeUI shell”Whatever path you choose, the application root uses one BeeUIProvider with explicit safe-area ownership:
import { AppHeader, BeeUIProvider, BottomActionBar, SafeArea, Screen,} from '@beemvp/beeui-ui';
export function AppShell() { return ( <BeeUIProvider> <Screen> <SafeArea edges={['top', 'left', 'right']}> <AppHeader title="BeeUI" /> </SafeArea> <SafeArea className="flex-1" edges={['left', 'right']}> {/* application content */} </SafeArea> <SafeArea edges={['bottom', 'left', 'right']}> <BottomActionBar>{/* actions */}</BottomActionBar> </SafeArea> </Screen> </BeeUIProvider> );}Read Provider & safe area before building a production shell.
Verify your install
Section titled “Verify your install”After installation:
- Confirm
npm ls @beemvp/beeui-ui @beemvp/beeui-core @beemvp/beeui-tokensresolves the current candidate0.86.2-rc.3when using@next. - Typecheck your application.
- Build or export for every platform you ship.
- Exercise at least one real BeeUI component under
BeeUIProvider. - For native applications, run the platform-specific guide’s native checks rather than treating a Web build as native evidence.
For exact release-channel rules, see the repository authority docs/dist-tag-policy.md.