SculptForge
ZBrush 스타일 조각으로 VFX·애니메이션·게임 제작
다중 도메인 프로젝트용 자체 호스팅 shadcn 레지스트리, 한 번 설치로 의존성 없이 전달
Self-hosted shadcn registry for multi-domain projects: design tokens, primitives, DataGrid and blocks. Install with one command, hand over with zero dependency on us.
디자인TypeScript · JavaScriptGitHub @RenoAI-Labs온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Self-hosted shadcn registry for multi-domain apps: OKLCH design tokens, 47 primitives and a virtualized DataGrid. Installs as source — no runtime dependency, clean handover.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
A self-hosted shadcn registry for building product UIs
across several domains — e-learning, admin, ERP and CMS — from one component
codebase.
Components are installed as source. npx shadcn add @reno/button writes a real
.tsx file into your repository and installs its npm dependencies. Nothing
calls back to this registry at runtime, so a project built with reno-ui keeps
building forever whether or not this registry exists.
Add the @reno namespace to your project's components.json:
Then install the theme and any components you need:README 전문 보기 ↗A self-hosted shadcn registry for building product UIs across several domains — e-learning, admin, ERP and CMS — from one component codebase.
Components are installed as source. npx shadcn add @reno/button writes a real
.tsx file into your repository and installs its npm dependencies. Nothing
calls back to this registry at runtime, so a project built with reno-ui keeps
building forever whether or not this registry exists.
Registry: https://ui.reno.ai.vn · License: MIT
Add the @reno namespace to your project's components.json:
{
"registries": {
"@reno": "https://ui.reno.ai.vn/r/{name}.json"
}
}
Then install the theme and any components you need:
npx shadcn@latest add @reno/theme-base
npx shadcn@latest add @reno/button
The registry is public. There is no token and no authentication.
src/components/ui/Point aliases.ui somewhere else first. That is every project that is already
running, not an edge case, and shadcn add overwrites a same-named file without
asking — installing @reno/data-grid alone pulls in button and checkbox,
so two of the project's own components go with it.
{
"aliases": { "ui": "@/components/reno/ui" },
"registries": { "@reno": "https://ui.reno.ai.vn/r/{name}.json" }
}
reno components then live beside the project's own instead of on top of them, and the two sets can be reconciled a screen at a time. Measured on a real project, 11 of 60 existing components shared a name with a reno item.
docs/handover-checklist.md carries the rest of the questions worth asking before the first install.
Three layers, each unaware of the one above it.
Tokens theme-base — one theme, OKLCH scales, radius, density,
typography, dark mode. Branded by overriding CSS variables.
↑
Primitives 52 components, most derived from shadcn/ui, plus a virtualized DataGrid
↑
Blocks dashboard-shell, crud-page, auth-pages (not built yet)
Blocks are deliberately not built yet. They must be derived from screens that actually shipped in a real project rather than guessed at, so they stay behind a validation gate until reno-ui has been used end to end on one.
Blocks import primitives. Primitives read tokens through CSS variables only —
never a hardcoded colour, and never a fixed control height. That constraint is
what lets a single <Button> render compact on a data-heavy screen and roomy on
a reading-heavy one, and it is enforced by lint (reno-tokens/no-raw-color)
rather than by convention.
There is one theme, not a set of domain presets. Four of those shipped until
2026-09-03 — elearning, admin, erp, cms — and they were removed: naming themes
after our own domains asks a project to pick one of ours, when a project arrives
with a brand colour and an opinion about spacing. What they encoded is a hue, a
radius and a density step, which are now settings. Override
--reno-brand-*, --radius and the --density-* scale in your own
globals.css; the Thương hiệu panel on
the showcase does it live, measures WCAG
contrast as you go, and hands you the exact block to paste.
See docs/design-tokens.md for the token contract, docs/icons.md for the icon library, naming convention and why brand logos stay out, and docs/data-grid-server-contract.md for what the DataGrid sends a backend.
The showcase is a complete admin portal — dashboard,
reports, a list page, settings with a permission matrix, and a profile — and its
shell, header, avatar menu, grid and settings layout are the fixed layout of
every project's admin portal. Positions and functions are the standard; brand
colour and style are per project, through tokens. The contract, its version
(admin-layout-standard v1) and the list of what may and may not vary are in
docs/admin-layout-standard.md. The parts a
project installs for it are the registry items page-header, user-menu,
quota-widget, attention-card, bulk-action-bar, row-actions, save-bar
and permission-matrix, beside the existing sidebar, stat-card, chart and
data-grid.
@reno/table is a styled <table> for light list views. @reno/data-grid is
the virtualized grid for admin and ERP: server-side paging/sorting/filtering,
column pinning, resizing and visibility, cross-page row selection, and built-in
empty, loading and error states.
They are separate registry items on purpose — a CMS project installing table
gets no TanStack in its bundle, and CI fails if that ever stops being true.
TanStack Table v9 was chosen partly because its features are tree-shakable.
Measured rather than assumed (npm run bench:tanstack, esbuild, minified, React
external):
| Build | Minified | Gzipped |
|---|---|---|
| v8.21.3, all features (v8 has no opt-out) | 53.0 kB | 14.1 kB |
| v9.2.4, the ten features DataGrid registers | 77.0 kB | 21.2 kB |
| v9.2.4, core row model only | 32.4 kB | 10.5 kB |
The tree-shaking is real — dropping to the core model cuts 58% — but DataGrid registers every feature, so as shipped it costs about 45% more than v8 would. The saving is available to a grid that lets a project opt features out, which this one does not do yet.
The grid never fetches. It emits state; you wire that to React Query, a server
action, or the URL via @reno/use-data-grid-url-state. See the server contract
doc for the wiring.
reno-ui targets modern browsers only, because Tailwind v4 and OKLCH colours do:
| Browser | Minimum |
|---|---|
| Safari | 16.4 |
| Chrome / Edge | 111 |
| Firefox | 128 |
Confirm this floor with a client before starting a project on reno-ui.
Runtime: React 19, Tailwind CSS v4. Node 20.19+ to work on this repository.
Tailwind v4 is a hard requirement and there will be no v3 compatibility mode —
supporting both would mean shipping every token twice, in two colour spaces that
do not agree. A project on v3 upgrades before adopting reno-ui;
docs/tailwind-v4-requirement.md covers what
that costs (measured on a real 433-file app), the @theme inline mapping that
lets a project keep its own palette, and an unsupported shim for getting value
out of the primitives in the meantime.
reno-ui is built for outsourced delivery, where the client must end up owning everything and depending on nobody.
node scripts/eject-registry.mjs --dir /path/to/client-project
scripts/verify-selfcontained.sh /path/to/client-project
The first removes the @reno entry from components.json — dev tooling, not a
build input — and proves no @reno/ reference remains. The second clones the
project into a clean directory and runs npm ci && npm run build to prove it
stands alone.
Ship docs/ui-components.md with the delivery. It records the origin and
license of every component the client now owns.
docs/handover-checklist.md is the full sequence, including the compatibility questions worth asking before a project starts rather than at delivery.
npm install
npm run dev # docs site at localhost:3000
npm run registry:build # regenerate public/r/*.json
npm run verify # static gates + lint + types + tests
npm run check:all # the generated-artifact and policy gates only
# The render gate needs a build and a running server, so it is separate:
npm run build && npx next start &
npm run check:render # opens the site in Chrome and asserts it draws
| Command | Purpose |
|---|---|
npm run theme:generate | Rebuild theme CSS from theme-presets.config.mjs |
npm run theme:sync | Rebuild theme cssVars from theme CSS |
npm run registry:assemble | Rebuild registry.json from registry/items/*.json |
npm run demos:generate | Rebuild the docs demo index |
npm run check:contrast | WCAG AA gate across the theme, both modes |
npm run check:provenance | License gate; regenerates the inventory in docs/ui-components.md |
npm run check:boundaries | Layering, framework-neutrality and bundle-split gate |
npm run check:render | Opens the built site in Chrome: rows render, no horizontal overflow, clean console |
npm run bench:data-grid | Scroll benchmark: 10k rows, three runs, prints FPS (not a CI gate — runner frame timing is noise) |
Generated files are never edited by hand — check:all fails if they drift from
their sources.
See CONTRIBUTING.md. Note in particular the licensing constraint on component sources: only shadcn/ui (MIT) and original code may be added.