|
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Conventional Commits |
| 4 | + |
| 5 | +This project uses [Conventional Commits](https://www.conventionalcommits.org/) to automate versioning and changelog generation via `semantic-release`. |
| 6 | + |
| 7 | +Every commit message must follow this format: |
| 8 | + |
| 9 | +``` |
| 10 | +<type>(<optional scope>): <description> |
| 11 | +``` |
| 12 | + |
| 13 | +### Commit types and their effect on versioning |
| 14 | + |
| 15 | +| Type | Description | Release | |
| 16 | +| ---------- | ------------------------------ | ------------------ | |
| 17 | +| `feat` | A new feature | Minor version bump | |
| 18 | +| `fix` | A bug fix | Patch version bump | |
| 19 | +| `perf` | A performance improvement | Patch version bump | |
| 20 | +| `chore` | Maintenance / tooling | No release | |
| 21 | +| `docs` | Documentation only | No release | |
| 22 | +| `refactor` | Code change, no feature or fix | No release | |
| 23 | +| `style` | Formatting, whitespace | No release | |
| 24 | +| `test` | Adding or updating tests | No release | |
| 25 | +| `ci` | CI/CD changes | No release | |
| 26 | +| `build` | Build system changes | No release | |
| 27 | + |
| 28 | +### Breaking changes |
| 29 | + |
| 30 | +A breaking change triggers a **major version bump** regardless of the commit type. Indicate it in one of two ways: |
| 31 | + |
| 32 | +**Option 1 — `!` suffix on the type:** |
| 33 | + |
| 34 | +``` |
| 35 | +feat!: remove deprecated myRef prop |
| 36 | +``` |
| 37 | + |
| 38 | +**Option 2 — `BREAKING CHANGE` footer:** |
| 39 | + |
| 40 | +``` |
| 41 | +feat: remove deprecated myRef prop |
| 42 | +
|
| 43 | +BREAKING CHANGE: The `myRef` prop has been removed. Use the standard `ref` prop instead. |
| 44 | +``` |
| 45 | + |
| 46 | +### More examples |
| 47 | + |
| 48 | +``` |
| 49 | +feat: add support for placeholder color prop |
| 50 | +fix: label stays in dirty position after clear() |
| 51 | +chore: upgrade tsup to v9 |
| 52 | +docs: update README installation steps |
| 53 | +``` |
| 54 | + |
| 55 | +## Development workflow |
| 56 | + |
| 57 | +```bash |
| 58 | +# Install dependencies |
| 59 | +npm install |
| 60 | + |
| 61 | +# Run tests |
| 62 | +npm test |
| 63 | + |
| 64 | +# Type-check |
| 65 | +npm run type-check |
| 66 | + |
| 67 | +# Build the library |
| 68 | +npm run build |
| 69 | + |
| 70 | +# Start the demo dev server (http://localhost:5173) |
| 71 | +npm run demo |
| 72 | +``` |
| 73 | + |
| 74 | +## Submitting changes |
| 75 | + |
| 76 | +1. Fork the repository and create a branch from `master`. |
| 77 | +2. Make your changes, following the Conventional Commits format for every commit. |
| 78 | +3. Ensure `npm test`, `npm run type-check`, and `npm run build` all pass locally. |
| 79 | +4. Open a pull request against `master`. The CI workflow will run automatically. |
| 80 | + |
| 81 | +## Setting up NPM_TOKEN for automated publishing |
| 82 | + |
| 83 | +Automated npm publishing is handled by `semantic-release` via the `release.yml` workflow. It requires a `NPM_TOKEN` secret in the GitHub repository settings. |
| 84 | + |
| 85 | +**Steps to configure:** |
| 86 | + |
| 87 | +1. Log in to [npmjs.com](https://www.npmjs.com) and go to **Access Tokens** in your account settings. |
| 88 | +2. Click **Generate New Token** and choose **Granular Access Token** (or Classic → **Automation** type). |
| 89 | +3. Grant the token **read and write** access to the `react-native-floating-labels` package. |
| 90 | +4. Copy the generated token. |
| 91 | +5. In the GitHub repository, go to **Settings → Secrets and variables → Actions**. |
| 92 | +6. Click **New repository secret**, name it `NPM_TOKEN`, and paste the token value. |
| 93 | + |
| 94 | +The `GITHUB_TOKEN` secret is automatically provided by GitHub Actions and requires no manual setup. |
| 95 | + |
| 96 | +## Releasing |
| 97 | + |
| 98 | +Releases are fully automated. When a PR is merged to `master`: |
| 99 | + |
| 100 | +1. The `CI` workflow runs tests, type-check, and build. |
| 101 | +2. On success, the `Release` workflow runs `semantic-release`. |
| 102 | +3. `semantic-release` analyzes commits since the last release, determines the next version, publishes to npm, creates a GitHub release, and commits an updated `CHANGELOG.md` back to `master`. |
| 103 | + |
| 104 | +You do **not** need to manually bump versions or tag releases. |
0 commit comments