SnapOtter/CONTRIBUTING.md

# Contributing to Stirling Image

Thanks for your interest in contributing. There are many ways to help beyond writing code: reporting bugs, suggesting features, improving docs, and adding translations.

## Issues

Before opening an issue, search existing ones to avoid duplicates.

- **Bug reports**: Include steps to reproduce, expected vs. actual behavior, and your environment (OS, Docker version, browser).
- **Feature requests**: Describe the problem you want solved, not just the solution. Context helps.
- **Questions**: Open an issue. We will do our best to respond quickly.

## Pull requests

1. **Open an issue first.** Describe what you want to change and why. Wait for a maintainer to confirm the direction before writing code.
2. **Fork the repo** and create a branch from `main`.
3. **Make your changes.** Follow the conventions in [CLAUDE.md](CLAUDE.md) (formatting, file structure, commit style).
4. **Test your changes.** Run `pnpm test` and `pnpm lint` before pushing. If you changed UI, run `pnpm test:e2e` too.
5. **Submit a PR.** Reference the issue number. Keep the title short and descriptive.

### Commit messages

We use [Conventional Commits](https://www.conventionalcommits.org/) for automated releases:

- `feat:` new feature (triggers a minor version bump)
- `fix:` bug fix (triggers a patch version bump)
- `docs:` documentation only
- `test:` adding or fixing tests
- `refactor:` code change that doesn't fix a bug or add a feature
- `chore:` maintenance (CI, deps, config)

Example: `feat: add HEIC to PNG conversion support`

### What makes a good PR

- One logical change per PR. If you need to refactor something to add a feature, that can be one PR, but don't mix unrelated changes.
- Clear commit messages that explain why, not just what.
- Tests for new behavior when possible.
- No unrelated formatting changes (Biome handles formatting).

## Development setup

Full instructions are in the [Developer Guide](https://stirling-image.github.io/stirling-image/guide/developer). The short version:

```bash
git clone https://github.com/stirling-image/stirling-image.git
cd stirling-image
pnpm install
pnpm dev        # starts both frontend and backend
```

The frontend runs at http://localhost:1349 and proxies API calls to the backend on port 13490.

### Running tests

```bash
pnpm lint           # Biome lint + format check
pnpm typecheck      # TypeScript across all workspaces
pnpm test           # unit + integration tests
pnpm test:e2e       # Playwright end-to-end tests
```

All of these run in CI on every PR. Make sure they pass locally first.

## Adding a new tool

Tools follow a consistent pattern. You will need to touch three places:

1. **Backend route** in `apps/api/src/routes/tools/` using `createToolRoute()` from the tool factory.
2. **Frontend settings component** in `apps/web/src/components/tools/` with the tool's UI controls.
3. **i18n entry** in `packages/shared/src/i18n/en.ts` with the tool's name and description.

See the [Developer Guide](https://stirling-image.github.io/stirling-image/guide/developer) for a walkthrough.

## Translations

We currently ship English only, but the i18n system is designed for easy extension. If you want to add a language, see the [Translation Guide](https://stirling-image.github.io/stirling-image/guide/translations).

## Code style

Biome handles formatting and linting. The rules are in `biome.json` and enforced by a pre-commit hook. Don't modify the Biome or TypeScript config files to silence warnings. Fix the code instead.

Quick summary:

- Double quotes, semicolons, 2-space indentation
- ES modules everywhere
- Zod for API input validation
- No `any` types without justification

## License

By contributing, you agree that your contributions will be licensed under the [MIT License](LICENSE).