|
| 1 | +# Contributing to OCPP DebugKit |
| 2 | + |
| 3 | +Thank you for your interest in contributing to OCPP DebugKit! This document |
| 4 | +covers setup, conventions, and the contribution workflow. |
| 5 | + |
| 6 | +## Getting Started |
| 7 | + |
| 8 | +### Prerequisites |
| 9 | + |
| 10 | +- **Node.js** >= 20.0.0 |
| 11 | +- **pnpm** 10.x (`npm install -g pnpm`) |
| 12 | +- **Git** |
| 13 | + |
| 14 | +### Local Setup |
| 15 | + |
| 16 | +```bash |
| 17 | +# Clone the repository |
| 18 | +git clone https://github.com/ocpp-debugkit/ocpp-debugkit.git |
| 19 | +cd ocpp-debugkit |
| 20 | + |
| 21 | +# Install dependencies |
| 22 | +pnpm install |
| 23 | + |
| 24 | +# Verify everything works |
| 25 | +pnpm lint |
| 26 | +pnpm test |
| 27 | +pnpm build |
| 28 | +``` |
| 29 | + |
| 30 | +## Monorepo Structure |
| 31 | + |
| 32 | +``` |
| 33 | +ocpp-debugkit/ |
| 34 | +├── packages/ |
| 35 | +│ ├── core/ # Data model, parser, normalizer, timeline, failure detection |
| 36 | +│ ├── scenarios/ # Predefined trace scenarios for testing |
| 37 | +│ ├── reporter/ # Report generators (Markdown, HTML) |
| 38 | +│ ├── cli/ # Command-line interface |
| 39 | +│ ├── replay/ # Replay engine (v0.2+) |
| 40 | +│ └── react/ # Reusable React components (v0.2+) |
| 41 | +├── apps/ |
| 42 | +│ └── web/ # Single Next.js app (landing, inspector, docs, blog) |
| 43 | +└── ... |
| 44 | +``` |
| 45 | + |
| 46 | +See [`AGENTS.md`](./AGENTS.md) for a detailed overview of the architecture, |
| 47 | +build commands, and package dependency graph. |
| 48 | + |
| 49 | +## Development Workflow |
| 50 | + |
| 51 | +### 1. Find or Create an Issue |
| 52 | + |
| 53 | +All work should be tracked via GitHub Issues. Check existing issues or create |
| 54 | +a new one using the appropriate issue template (bug report, feature request, |
| 55 | +or scenario request). |
| 56 | + |
| 57 | +### 2. Create a Branch |
| 58 | + |
| 59 | +```bash |
| 60 | +git checkout -b feat/<scope>-<description> |
| 61 | +``` |
| 62 | + |
| 63 | +### 3. Make Your Changes |
| 64 | + |
| 65 | +- Follow the code style (TypeScript strict, Prettier, ESLint). |
| 66 | +- Write tests for the behavior you introduce. |
| 67 | +- Update documentation as needed. |
| 68 | + |
| 69 | +### 4. Verify Locally |
| 70 | + |
| 71 | +```bash |
| 72 | +pnpm lint |
| 73 | +pnpm typecheck |
| 74 | +pnpm test |
| 75 | +pnpm build |
| 76 | +``` |
| 77 | + |
| 78 | +### 5. Add a Changeset |
| 79 | + |
| 80 | +If your PR changes publishable package behavior, add a changeset: |
| 81 | + |
| 82 | +```bash |
| 83 | +pnpm changeset |
| 84 | +``` |
| 85 | + |
| 86 | +This creates a file in `.changeset/` describing the change and which packages |
| 87 | +are affected. |
| 88 | + |
| 89 | +### 6. Open a Pull Request |
| 90 | + |
| 91 | +- Use the PR template. |
| 92 | +- Link the issue with `Closes #N`. |
| 93 | +- Ensure CI passes (lint, typecheck, test, build). |
| 94 | + |
| 95 | +## Conventions |
| 96 | + |
| 97 | +### Commit Messages |
| 98 | + |
| 99 | +This project uses [Conventional Commits](https://www.conventionalcommits.org/): |
| 100 | + |
| 101 | +``` |
| 102 | +feat(core): implement trace parser for JSON input |
| 103 | +fix(cli): handle missing trace file gracefully |
| 104 | +docs: add architecture overview to docs |
| 105 | +chore: add vitest configuration |
| 106 | +test(core): add parser edge case tests |
| 107 | +``` |
| 108 | + |
| 109 | +### Branch Naming |
| 110 | + |
| 111 | +``` |
| 112 | +feat/<scope>-<description> # e.g. feat/core-parse-trace |
| 113 | +fix/<scope>-<description> # e.g. fix/cli-stdout-encoding |
| 114 | +chore/<description> # e.g. chore/ci-workflow |
| 115 | +docs/<description> # e.g. docs/readme |
| 116 | +test/<description> # e.g. test/core-coverage |
| 117 | +``` |
| 118 | + |
| 119 | +### Code Style |
| 120 | + |
| 121 | +- **TypeScript strict mode** — no `any` without justification. |
| 122 | +- **Prettier** for formatting (single quotes, trailing commas, 100 char width). |
| 123 | +- **ESLint** with `typescript-eslint` strict rules. |
| 124 | +- Use `import type` for type-only imports. |
| 125 | + |
| 126 | +### Testing |
| 127 | + |
| 128 | +- Tests use **Vitest**. |
| 129 | +- Test files: `*.test.ts` / `*.spec.ts`. |
| 130 | +- Tests live next to the code they test. |
| 131 | +- Coverage target: 70%+ for core package. |
| 132 | + |
| 133 | +## Security Guidelines |
| 134 | + |
| 135 | +OCPP DebugKit processes untrusted input (trace files, pasted content). When |
| 136 | +working on parsing, CLI, or UI code: |
| 137 | + |
| 138 | +- **Validate all external input** — CLI args, file content, paste input. |
| 139 | +- **Safe JSON parsing** — always use try/catch and enforce size limits. |
| 140 | +- **No dynamic code execution** — no `eval()`, `Function()` on untrusted input. |
| 141 | +- **No prototype pollution** — validate object shapes, use safe parsing. |
| 142 | +- **Path safety** — validate file paths, prevent path traversal. |
| 143 | +- **Safe rendering** — no `dangerouslySetInnerHTML`, no unsafe HTML injection. |
| 144 | +- **Browser-local processing** — no automatic uploading of user data. |
| 145 | +- **No secrets in committed files** — no credentials, API keys, or tokens. |
| 146 | +- **No sensitive data in committed artifacts** — use synthetic data in trace |
| 147 | + fixtures, sample data, and test data. Real station IDs, transaction IDs, IPs, |
| 148 | + or personal information must not appear in committed files. User-loaded |
| 149 | + traces and runtime-generated reports are **not** subject to this rule — they |
| 150 | + contain the user's own data and must not be redacted. |
| 151 | + |
| 152 | +If you discover a security vulnerability, please see the |
| 153 | +[Security Policy](./SECURITY.md) for responsible disclosure. |
| 154 | + |
| 155 | +## AI-Assisted Development |
| 156 | + |
| 157 | +Maintainers may use AI-assisted development tools, but all contributions must |
| 158 | +be reviewed, tested, documented, and scoped like normal engineering work. |
| 159 | +AI-generated code is held to the same standards as any other contribution: it |
| 160 | +must pass CI, include tests, be security-reviewed, and be understandable by a |
| 161 | +human reviewer. |
| 162 | + |
| 163 | +Contributors using AI agents can point them at [`AGENTS.md`](./AGENTS.md) for |
| 164 | +a structured overview of this repository's architecture, conventions, and build |
| 165 | +system. [`CURRENT_STATE.md`](./CURRENT_STATE.md) reflects what has been built |
| 166 | +so far and what is in progress — use it to orient your agent before starting |
| 167 | +work. |
| 168 | + |
| 169 | +No AI tool preference is assumed or required. The project does not endorse any |
| 170 | +specific AI tool. |
| 171 | + |
| 172 | +## Living Documents |
| 173 | + |
| 174 | +The following documents are updated as part of the work, inside the PR: |
| 175 | + |
| 176 | +| Document | When updated | |
| 177 | +|----------|-------------| |
| 178 | +| `CURRENT_STATE.md` | Inside every PR, before merge | |
| 179 | +| `AGENTS.md` | When architecture, packages, or build commands change | |
| 180 | +| `CONTRIBUTING.md` | When contribution process or conventions change | |
| 181 | +| `ROADMAP.md` | At each milestone boundary | |
| 182 | +| `README.md` | When description, badges, quickstart, or links change | |
| 183 | + |
| 184 | +## Questions? |
| 185 | + |
| 186 | +- Open a [GitHub Issue](https://github.com/ocpp-debugkit/ocpp-debugkit/issues) |
| 187 | +- Read the [documentation](https://ocppdebugkit.com/docs) |
| 188 | +- Check the [roadmap](./ROADMAP.md) |
0 commit comments