|
| 1 | +# Community & Contributing |
| 2 | + |
| 3 | +Welcome to the StatikAPI community. This page explains how the project is maintained, how you can contribute, and how the documentation site is kept in sync with the repository. It also summarizes the monorepo layout so you can find your way around quickly. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## How the project is maintained |
| 8 | + |
| 9 | +StatikAPI is developed in a JavaScript monorepo and released under the MIT license. We prioritize small, iterative changes with clear commit messages and automated CI checks. |
| 10 | + |
| 11 | +- Issues and feature requests are tracked on GitHub using issue templates. |
| 12 | +- Pull requests must pass linting, tests, and basic manual checks before merge. |
| 13 | +- Releases are cut from git tags and published via GitHub Actions to npm. The CLI bundles a prebuilt copy of the preview UI during publish. |
| 14 | + |
| 15 | +See: [`./.github/workflows/release.yml`](../.github/workflows/release.yml) |
| 16 | + |
| 17 | +--- |
| 18 | + |
| 19 | +## Monorepo at a glance |
| 20 | + |
| 21 | +``` |
| 22 | +. |
| 23 | +├─ packages/ |
| 24 | +│ ├─ cli/ → The `statikapi` CLI (build, dev, preview) |
| 25 | +│ ├─ core/ → Shared utilities and internal helpers |
| 26 | +│ ├─ ui/ → React preview UI served at /_ui |
| 27 | +│ └─ create-statikapi/ → Project scaffolder |
| 28 | +├─ example/ → Minimal example projects |
| 29 | +├─ docs/ → OSS documentation content (MDX) |
| 30 | +├─ .github/ → Issue templates and release workflows |
| 31 | +└─ scripts, configs, etc. |
| 32 | +``` |
| 33 | + |
| 34 | +- Node version is pinned via [`.nvmrc`](../.nvmrc) (Node 22). |
| 35 | +- Editor and formatting defaults live in [`.editorconfig`](../.editorconfig). |
| 36 | + |
| 37 | +--- |
| 38 | + |
| 39 | +## How to contribute |
| 40 | + |
| 41 | +We welcome bug reports, fixes, features, docs improvements, and examples. |
| 42 | + |
| 43 | +1. **Discuss**: If an issue does not exist, open one first (bug or feature template). |
| 44 | + - Bug: [`.github/ISSUE_TEMPLATE/bug_report.md`](../.github/ISSUE_TEMPLATE/bug_report.md) |
| 45 | + - Feature: [`.github/ISSUE_TEMPLATE/feature_request.md`](../.github/ISSUE_TEMPLATE/feature_request.md) |
| 46 | +2. **Fork and branch** off `main`. Use a descriptive branch name like `feat/route-aliases`. |
| 47 | +3. **Develop locally** (see quickstart below). Keep commits small and focused. |
| 48 | +4. **Tests and lint** must pass before opening a PR: |
| 49 | + ```bash |
| 50 | + pnpm -w lint |
| 51 | + pnpm -w test |
| 52 | + ``` |
| 53 | +5. **Open a PR** using the pull request template. Explain the change and link issues. |
| 54 | + |
| 55 | +Read the full guide: [`CONTRIBUTING.md`](../CONTRIBUTING.md) and the PR template: [`.github/PULL_REQUEST_TEMPLATE.md`](../.github/PULL_REQUEST_TEMPLATE.md). |
| 56 | + |
| 57 | +--- |
| 58 | + |
| 59 | +## Commit style |
| 60 | + |
| 61 | +Use a short, imperative subject and include an optional body explaining the “what” and “why”. |
| 62 | + |
| 63 | +``` |
| 64 | +type(scope): subject |
| 65 | +``` |
| 66 | + |
| 67 | +Common types include: `feat`, `fix`, `perf`, `refactor`, `build`, `ci`, `docs`, `style`, `test`, `chore`, `security`, `deps`, `release`. |
| 68 | + |
| 69 | +See details and examples in [`CONTRIBUTING.md`](../CONTRIBUTING.md#commit-style). |
| 70 | + |
| 71 | +--- |
| 72 | + |
| 73 | +## Docs: how it works |
| 74 | + |
| 75 | +The documentation you are reading is maintained **in the same repository** under `docs/` as MDX files. The website consumes these MDX files directly. When a docs PR is merged to the default branch: |
| 76 | + |
| 77 | +- The MDX files are built and deployed by the website pipeline. |
| 78 | +- Any change under `docs/` automatically updates the live Docs site on the next deployment. |
| 79 | +- The left‑hand navigation is driven by JSON/MDX metadata (for example, `_nav.json`). |
| 80 | + |
| 81 | +Guidelines for docs changes: |
| 82 | + |
| 83 | +- Keep titles, slugs, and folder structure stable to avoid broken links. |
| 84 | +- Prefer small, atomic docs PRs scoped to one page or feature. |
| 85 | +- Include runnable or copy‑pasteable examples; verify commands. |
| 86 | + |
| 87 | +--- |
| 88 | + |
| 89 | +## Local development quickstart |
| 90 | + |
| 91 | +Requirements: Node 22, pnpm 9. |
| 92 | + |
| 93 | +```bash |
| 94 | +git clone https://github.com/zonayedpca/statikapi.git |
| 95 | +cd statikapi |
| 96 | +pnpm install |
| 97 | + |
| 98 | +# Start development loop (CLI + UI preview) |
| 99 | +pnpm dev |
| 100 | + |
| 101 | +# Or run a specific example |
| 102 | +pnpm -C example/basic dev |
| 103 | +``` |
| 104 | + |
| 105 | +Useful scripts: |
| 106 | +- `pnpm -w lint` and `pnpm -w format` to keep code style consistent. |
| 107 | +- `pnpm -r test` to run tests across packages. |
| 108 | +- `pnpm -C packages/ui build` to build the preview UI (the CLI bundles it on publish). |
| 109 | + |
| 110 | +--- |
| 111 | + |
| 112 | +## Issue workflow |
| 113 | + |
| 114 | +- Use the provided templates for clear reports and proposals. |
| 115 | +- Include reproduction steps and expected behavior for bugs. |
| 116 | +- For features, describe the problem, proposed solution (flags, config, UI), and alternatives. |
| 117 | +- Security issues should be reported privately (see Security below). |
| 118 | + |
| 119 | +Templates: |
| 120 | +- Bug: [`.github/ISSUE_TEMPLATE/bug_report.md`](../.github/ISSUE_TEMPLATE/bug_report.md) |
| 121 | +- Feature: [`.github/ISSUE_TEMPLATE/feature_request.md`](../.github/ISSUE_TEMPLATE/feature_request.md) |
| 122 | + |
| 123 | +--- |
| 124 | + |
| 125 | +## Code of Conduct and Security |
| 126 | + |
| 127 | +- Be respectful and constructive. See [`CODE_OF_CONDUCT.md`](../CODE_OF_CONDUCT.md). |
| 128 | +- Report vulnerabilities privately as described in [`SECURITY.md`](../SECURITY.md). |
| 129 | + - Email: contact@statikapi.com |
| 130 | + - Please include environment, version/commit, impact, and steps to reproduce. |
| 131 | + |
| 132 | +--- |
| 133 | + |
| 134 | +## Docs and site deployment |
| 135 | + |
| 136 | +- Docs live under `docs/` and are version‑agnostic at the moment. |
| 137 | +- The site build watches `docs/` and republishes changes automatically after merge. |
| 138 | +- Release automation for packages is separate and handled by GitHub Actions (`release.yml`). |
| 139 | + |
| 140 | +If a docs change must land at the same time as a code change, note that in your PR body so maintainers can coordinate the merge order. |
| 141 | + |
| 142 | +--- |
| 143 | + |
| 144 | +## Questions and discussion |
| 145 | + |
| 146 | +- File an issue for bugs or feature requests. |
| 147 | +- For general questions, you can also open a “question” issue if needed. |
| 148 | +- We’ll add Discussions as the community grows. |
| 149 | + |
| 150 | +Thank you for helping improve StatikAPI. |
0 commit comments