|
1 | | -# How to Contribute |
| 1 | +# Contributing to tc-lib-unicode |
2 | 2 |
|
| 3 | +Thank you for your interest in contributing to **tc-lib-unicode**. |
| 4 | +Contributions of all kinds are welcome: bug reports, bug fixes, documentation improvements, new features, and refactors. |
3 | 5 |
|
4 | | -## Reporting a bug |
| 6 | +Please take a moment to read this guide before opening an issue or pull request. |
5 | 7 |
|
6 | | -* **Do not open up a GitHub issue if the bug is a security vulnerability**, and instead to refer to our [Security policy](SECURITY.md). |
| 8 | +--- |
7 | 9 |
|
8 | | -* Ensure the bug was not already reported by searching on GitHub Issues. |
| 10 | +## Table of Contents |
9 | 11 |
|
10 | | -* If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a **title and clear description**, as much relevant information as possible, and a **code sample** or an **executable test case** demonstrating the expected behavior that is not occurring. |
| 12 | +- [Code of Conduct](#code-of-conduct) |
| 13 | +- [Security Vulnerabilities](#security-vulnerabilities) |
| 14 | +- [Getting Started](#getting-started) |
| 15 | +- [Reporting a Bug](#reporting-a-bug) |
| 16 | +- [Submitting a Bug Fix](#submitting-a-bug-fix) |
| 17 | +- [Proposing a New Feature](#proposing-a-new-feature) |
| 18 | +- [Development Workflow](#development-workflow) |
| 19 | +- [Coding Standards](#coding-standards) |
| 20 | +- [Testing](#testing) |
| 21 | +- [Pull Request Guidelines](#pull-request-guidelines) |
| 22 | +- [Commit Message Guidelines](#commit-message-guidelines) |
11 | 23 |
|
| 24 | +--- |
12 | 25 |
|
13 | | -## Submitting a bug fix |
| 26 | +## Code of Conduct |
14 | 27 |
|
15 | | -* Open a new GitHub pull request with the patch. |
| 28 | +This project follows the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). By participating you agree to abide by its terms. Please report unacceptable behaviour to [[email protected]](mailto:[email protected]). |
16 | 29 |
|
17 | | -* Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable. |
| 30 | +--- |
18 | 31 |
|
19 | | -* Ensure the new code is following the existing conventions and the unit test coverage is 100%. |
| 32 | +## Security Vulnerabilities |
20 | 33 |
|
21 | | -* Before submitting, please run the following command locally to ensure the code is passing the automatic checks: `make buildall`. |
| 34 | +**Do not open a public GitHub issue for security vulnerabilities.** |
| 35 | +Please follow the [Security Policy](SECURITY.md) and report them privately. |
22 | 36 |
|
| 37 | +--- |
23 | 38 |
|
24 | | -## Add a new feature or change an existing one |
| 39 | +## Getting Started |
25 | 40 |
|
26 | | -* Before writing any code please suggest the change by opening a new Feature Request on Issues. |
| 41 | +### Requirements |
| 42 | + |
| 43 | +- PHP **≥ 8.1** |
| 44 | +- [Composer](https://getcomposer.org/) v2 |
| 45 | +- `make`, `git` |
| 46 | +- Optional: `rpmbuild` (RPM packaging), `dpkg-buildpackage` (DEB packaging) |
| 47 | + |
| 48 | +### Local setup |
| 49 | + |
| 50 | +```bash |
| 51 | +git clone https://github.com/tecnickcom/tc-lib-unicode.git |
| 52 | +cd tc-lib-unicode |
| 53 | +make buildall |
| 54 | +``` |
| 55 | + |
| 56 | +To verify everything is working after a change: |
| 57 | + |
| 58 | +```bash |
| 59 | +make qa |
| 60 | +``` |
| 61 | + |
| 62 | +This runs linting, static analysis, and the full unit-test suite with coverage. |
| 63 | + |
| 64 | +--- |
| 65 | + |
| 66 | +## Reporting a Bug |
| 67 | + |
| 68 | +Before opening an issue: |
| 69 | + |
| 70 | +1. **Check the [Security Policy](SECURITY.md)** — if the bug is a security vulnerability, do not file a public issue. |
| 71 | +2. **Search [existing issues](https://github.com/tecnickcom/tc-lib-unicode/issues)** to avoid duplicates. |
| 72 | + |
| 73 | +If no existing issue matches, [open a new one](https://github.com/tecnickcom/tc-lib-unicode/issues/new) and include: |
| 74 | + |
| 75 | +- A **clear title and description** of the problem. |
| 76 | +- The **library version** (`composer show tecnickcom/tc-lib-unicode`) and PHP version. |
| 77 | +- A **minimal, self-contained reproduction** — a short PHP script or a failing PHPUnit test case is ideal. |
| 78 | +- **Expected vs. actual behaviour** — what you expected to happen and what actually happened. |
| 79 | +- Any relevant **stack trace or error output**. |
| 80 | + |
| 81 | +The more precise and reproducible the report, the faster it can be triaged and fixed. |
| 82 | + |
| 83 | +--- |
| 84 | + |
| 85 | +## Submitting a Bug Fix |
| 86 | + |
| 87 | +1. [Fork the repository](https://github.com/tecnickcom/tc-lib-unicode/fork) and create a branch from `main`: |
| 88 | + ```bash |
| 89 | + git checkout -b fix/short-description-of-bug |
| 90 | + ``` |
| 91 | +2. Make your changes, following the [Coding Standards](#coding-standards) below. |
| 92 | +3. Add or update unit tests to cover the changes. |
| 93 | +4. Run the full quality-assurance suite locally and ensure it passes: |
| 94 | + ```bash |
| 95 | + make qa |
| 96 | + ``` |
| 97 | +5. Commit your changes (see [Commit Message Guidelines](#commit-message-guidelines)). |
| 98 | +6. Open a pull request against `main` and fill in the PR template: |
| 99 | + - Describe the problem and your solution. |
| 100 | + - Reference the related issue number (e.g. `Fixes #123`). |
| 101 | + |
| 102 | +--- |
| 103 | + |
| 104 | +## Proposing a New Feature |
| 105 | + |
| 106 | +Before writing any code: |
| 107 | + |
| 108 | +1. **Open a Feature Request** on [GitHub Issues](https://github.com/tecnickcom/tc-lib-unicode/issues/new) describing the use case and proposed API. |
| 109 | +2. Wait for feedback from the maintainer. This avoids investing time in a direction that may not be accepted. |
| 110 | + |
| 111 | +Once the feature is agreed upon, follow the same branch → code → test → PR workflow as for bug fixes, using a branch named `feature/short-description`. |
| 112 | + |
| 113 | +--- |
| 114 | + |
| 115 | +## Development Workflow |
| 116 | + |
| 117 | +The `Makefile` exposes all common development tasks: |
| 118 | + |
| 119 | +| Command | Description | |
| 120 | +|---------|-------------| |
| 121 | +| `make qa` | Run linting, static analysis, tests, and reports | |
| 122 | +| `make test` | Run PHPUnit with code coverage | |
| 123 | +| `make lint` | Check coding standards (PHPCS, PHPMD, PHPStan) | |
| 124 | +| `make codefix` | Auto-fix coding standard violations (PHPCBF) | |
| 125 | +| `make buildall` | Install dependencies, fix style, run QA, and build packages | |
| 126 | +| `make clean` | Remove `vendor/` and `target/` directories | |
| 127 | +| `make server` | Start the built-in PHP development server for the examples | |
| 128 | + |
| 129 | +Run `make help` to see the full list of available targets. |
| 130 | + |
| 131 | +--- |
| 132 | + |
| 133 | +## Coding Standards |
| 134 | + |
| 135 | +- The codebase follows **PSR-12** for formatting. |
| 136 | +- Run `make codefix` to auto-fix style violations before committing. |
| 137 | +- Run `make lint` to catch remaining issues (PHPCS, PHPMD, PHPStan). |
| 138 | +- All source files live under `src/`, all tests under `test/`. |
| 139 | +- Use strict types and explicit visibility on all class members. |
| 140 | +- Avoid introducing new external dependencies without prior discussion. |
| 141 | + |
| 142 | +--- |
| 143 | + |
| 144 | +## Testing |
| 145 | + |
| 146 | +Tests are written with [PHPUnit](https://phpunit.de/) and live in `test/`. |
| 147 | + |
| 148 | +```bash |
| 149 | +# Run the full test suite with coverage |
| 150 | +make test |
| 151 | + |
| 152 | +# Run a specific test file |
| 153 | +XDEBUG_MODE=coverage ./vendor/bin/phpunit test/HTMLTest.php |
| 154 | +``` |
| 155 | + |
| 156 | +Requirements for contributions: |
| 157 | + |
| 158 | +- Every bug fix must be accompanied by a regression test that fails before the fix and passes after. |
| 159 | +- Every new feature must be accompanied by tests that cover both the happy path and edge cases. |
| 160 | + |
| 161 | +Coverage reports are generated in `target/coverage/`. |
| 162 | + |
| 163 | +--- |
| 164 | + |
| 165 | +## Pull Request Guidelines |
| 166 | + |
| 167 | +- Target the `main` branch. |
| 168 | +- Keep PRs focused — one fix or feature per PR. |
| 169 | +- Ensure `make qa` passes locally before opening the PR. |
| 170 | +- Do not bump the version number in your PR; that is handled by the maintainer at release time. |
| 171 | +- Be responsive to review feedback; stale PRs may be closed after an extended period of inactivity. |
| 172 | + |
| 173 | +--- |
| 174 | + |
| 175 | +## Commit Message Guidelines |
| 176 | + |
| 177 | +Use concise, imperative-mood commit messages: |
| 178 | + |
| 179 | +``` |
| 180 | +fix: correct path traversal in font loader |
| 181 | +feat: add support for XYZ |
| 182 | +test: add regression test for #123 |
| 183 | +docs: update CONTRIBUTING workflow |
| 184 | +refactor: extract text measurement into helper |
| 185 | +``` |
| 186 | + |
| 187 | +Prefix tags: `fix`, `feat`, `test`, `docs`, `refactor`, `chore`, `ci`. |
| 188 | +Reference issues where relevant: `fix: correct X (closes #42)`. |
| 189 | + |
| 190 | +--- |
| 191 | + |
| 192 | +## Questions? |
| 193 | + |
| 194 | +If you have a question that is not covered here, feel free to open a [GitHub Discussion ](https://github.com/tecnickcom/tc-lib-unicode/discussions) or contact the maintainer at [[email protected]](mailto:[email protected]). |
0 commit comments