Open app

Developing

Contributing

Contributions are welcome. Both applications are independent projects with their own tooling; pick the one you want to work on.

Built with AI assistance

rollnote is developed with substantial help from AI coding assistants (Claude Code). Each repository’s CLAUDE.md captures the conventions that assistant works to, and much of the code, tests, and this documentation was written or reviewed with AI in the loop. Every change is still human-reviewed before it lands. You are welcome to contribute with or without AI assistance - the same standards apply either way.

Local setup

Each repo uses pnpm. The API needs a Postgres database, which its dev compose file provides.

API:

cd rollnote-api
pnpm install
docker compose -f dev.compose.yml up -d   # Postgres
cp .env.example .env.local                # then fill in the blanks
pnpm start:dev                            # watch mode on :3000

When NODE_ENV is not production, the API mounts an interactive Swagger UI at /api - the fastest way to explore endpoints.

Frontend:

cd rollnote-front
pnpm install
pnpm start                                # dev server on :4200

The dev build points at http://localhost:3000, so start the API first.

Tests

# API
pnpm test          # unit (Jest, no external deps)
pnpm test:int      # integration (throwaway Postgres + Mailpit via testcontainers)

# Frontend
pnpm test          # unit (Vitest, jsdom)
pnpm e2e           # end-to-end (Playwright, Chromium)

Integration tests need a Docker-compatible socket. Email in tests always goes through Mailpit, never a real SMTP relay.

Branch and release workflow

  • Feature work branches off develop and targets it in a pull request.
  • Every PR to develop bumps the version in that repo’s package.json following semver (patch for fixes and refactors, minor for features, major for breaking changes).
  • The frontend’s release notes are the in-app changelog, seeded from the API. When a frontend change is user-facing, its package.json version and the latest changelog entry are kept in lockstep.

The full conventions live in each repo’s CLAUDE.md.

Code style

  • API: one module per domain, services touch only their own schema, DTOs validated with class-validator.
  • Frontend: standalone components with OnPush and signals; reach for a PrimeNG component before custom markup; SCSS scoped per component.

Where to send changes

The canonical source is on Forgejo. Open issues and pull requests there.