Materializr
오픈소스 파라메트릭 3D CAD로 제약 스케치·솔리드 모델·나사·SVG·텍스트 조각·STL/STEP 내보내기를 지원합니다
Design System based on react-aria and Tailwind CSS
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
React implementation of the Marigold Design System based on react-aria and Tailwind CSS.
Do you want to start using the Marigold Design System?
Then get started in the Marigold documentation.
Open a terminal and navigate to a folder of your choice:
• clone the project git clone https://github.com/marigold-ui/marigold.git
• navigate to the new folder cd marigold
• install the packages using pnpm install
To start storybook use the following command in the root:
• pnpm sb
• open localhost:6006README 전문 보기 ↗React implementation of the Marigold Design System based on react-aria and Tailwind CSS.
Check out our latest release notes
Do you want to start using the Marigold Design System?
Then get started in the Marigold documentation.
Open a terminal and navigate to a folder of your choice:
git clone https://github.com/marigold-ui/marigold.gitcd marigoldpnpm installTo start storybook use the following command in the root:
pnpm sbTo start documentation follow these steps:
cd docspnpm dev| Command | Description |
|---|---|
| pnpm dev | Start the documentation app in dev mode. |
| pnpm start | Start the documentation app in production mode. |
| pnpm sb | Start Storybook using the components and system source folders. |
| pnpm build | Build components and theme packages. |
| pnpm build:docs | Build the documentation app. |
| pnpm build:sb | Build the Storybook configuration. |
| pnpm build:themes | Build all theme packages. |
| pnpm registry | Run the documentation registry task. |
| pnpm build:component-props | Generate/build component props tables for the docs. |
| pnpm test | Run tests with Vitest. |
| pnpm test:coverage | Run tests with coverage. |
| pnpm test:ci | Run tests for CI. |
| pnpm test:sb | Run Storybook component tests. |
| pnpm clean | Remove node_modules, dist, .next, .turbo, coverage, and storybook-static directories. |
| pnpm clean:build | Remove dist folders and coverage reports. |
| pnpm lint | Lint the repository with ESLint. |
| pnpm lint:prose | Lint docs prose with Vale. |
| pnpm format | Format files with Prettier. |
| pnpm format:check | Check formatting without writing (what CI runs). |
| pnpm format:fix | Format and attempt to fix with Prettier. |
| pnpm typecheck | Build docs, then run TypeScript type checking (no emit). |
| pnpm typecheck:only | Run TypeScript type checking only (no emit). |
| pnpm changeset | Run the Changesets CLI. |
Releases are published by CI, not locally. .github/workflows/release.yml runs
changesets/action on every push to main: it either opens a
"release: version packages" PR that consumes the pending changesets, or, once that PR is merged,
publishes the bumped packages to npm.
So the only thing you do by hand is add a changeset with pnpm changeset when your change should
cause a version bump.
Prereleases use changesets pre mode,
which lives on main (there is no separate release branch). The mode is recorded in
.changeset/pre.json, and pnpm changeset publish derives the npm dist-tag from its tag field,
so while pre mode is active, everything publishes to that tag instead of latest.
pnpm changeset pre enter rc # start publishing 18.0.0-rc.x to the "rc" dist-tag
pnpm changeset pre exit # go back to regular releases on "latest"
Two things worth knowing:
package.json, not from the tag. Switching
channel mid-prerelease continues the count (18.0.0-beta.4 → 18.0.0-rc.5) rather than resetting it.npm dist-tag add <pkg>@<new-version> <old-tag>)
or remove (npm dist-tag rm <pkg> <old-tag>) it per package after the first publish on the new channel.