|
| 1 | +# Repository Guidelines |
| 2 | + |
| 3 | +Concise guide for contributing to `launch.css`. Keep changes minimal, readable, and aligned with the classless CSS philosophy. |
| 4 | + |
| 5 | +## Project Structure & Module Organization |
| 6 | +- `packages/main`: Core framework. Sass sources live in `src/` (partials prefixed with `_`); compiled CSS in `dist/`. |
| 7 | +- `apps/docs`: Vite-powered docs site. Use it to preview component changes and documentation updates. |
| 8 | +- `examples/website`: Minimal Vite example consuming the package. |
| 9 | +- Root configs: `dprint.json` for formatting, `bun.lock`/`package.json` for workspace tooling, `cover.jpeg` for branding assets. |
| 10 | + |
| 11 | +## Setup, Build, and Development Commands |
| 12 | +- Install dependencies: `bun install`. |
| 13 | +- Build everything: `bun run build` (delegates to workspace scripts via `wsu`). |
| 14 | +- Local dev (all workspaces): `bun run dev` to run available `dev` scripts (Sass watch in `packages/main`, Vite dev server in docs/examples). |
| 15 | +- Lint/format: `bun run lint` to check formatting; `bun run format` to apply `dprint`. |
| 16 | +- Tests: `bun run test` (runs workspace tests such as `publint` for the package). |
| 17 | + |
| 18 | +## Coding Style & Naming Conventions |
| 19 | +- Formatting: tabs with width 4 (`dprint` enforced). Run `bun run format` before pushing. |
| 20 | +- Sass: keep specificity low; target semantic elements/ARIA instead of custom classes. Reuse tokens from `src/_variables.scss`; prefer mixins over repetition. |
| 21 | +- Files: new partials should be named `_feature.scss` and imported in `_index.scss`; keep public API limited to compiled `dist/index.css`. |
| 22 | +- JS/TS (docs/examples): ES modules, concise imports, single-responsibility utilities; keep Vite configs minimal. |
| 23 | + |
| 24 | +## Testing Guidelines |
| 25 | +- For visual changes, verify in `apps/docs` and `examples/website` across light/dark themes and both `data-layout` modes (`website`, `dashboard`). |
| 26 | +- No hard coverage target; favor small, verifiable changes and manual spot checks for regressions. |
| 27 | + |
| 28 | +## Commit & Pull Request Guidelines |
| 29 | +- Commits: short, imperative summaries (e.g., `Fix spacing for cards`); scope one logical change per commit; reference issues with `#id` when applicable. |
| 30 | +- PRs: include a concise summary, testing notes (commands run), and before/after screenshots or links for UI-affecting changes. Update README/docs when behavior or APIs change. |
| 31 | +- Keep branches up to date with `main` and resolve conflicts locally; avoid force-pushing shared branches. |
0 commit comments