Contribute to ElixirV4

Contribute a focused change by tracing the existing behavior, checking its callers, and providing evidence that it works. This page connects the application repository's contribution instructions to the backend workflows documented here.

Project orientationCopy Anchor Link

ElixirV4 contains a Next.js frontend at the root and a separate Express/TypeScript backend under backend/. The backend uses Prisma and PostgreSQL for accounts, clubs, events, registrations, blogs, mentors, and testimonials.

The developer handbook lives in elixir-docs, a separate Next.js/Fumadocs repository. Application code and contribution rules remain authoritative; these pages explain the implemented behavior and how to work with it. Submit implementation changes to ElixirV4 and handbook changes to elixir-docs, linking related PRs when both are affected.

Sourcebackend/package.json

SourceCONTRIBUTING.md

Before you startCopy Anchor Link

Read the current CONTRIBUTING.md and follow Backend Quickstart for Git, Node.js/npm, PostgreSQL, local environment configuration, dependency installation, and startup. The backend's locked Prisma packages require Node.js 18.18 or newer; CI selects Node.js 20. Root frontend commands and backend commands run in different package directories.

The contribution instructions ask you to search existing issues and PRs, check for overlapping work, and open an issue before implementing a non-trivial change. They also require a working branch rather than development directly on main. Keep credentials and private data out of issues, commits, logs, and review evidence.

Sourcebackend/package-lock.json

Find an area to contributeCopy Anchor Link

Browse existing issues and pull requests, then reproduce or describe the behavior before choosing an implementation. No particular issue label or triage process is assumed here.

For backend work, start with the relevant router in backend/src/routes/, follow its middleware and controller in backend/src/controllers/, and inspect validators in backend/src/validators/. Database work starts at backend/prisma/schema.prisma and its migrations. Search frontend consumers under src/ for affected paths and fields.

Use Backend Architecture for execution flow, the API Reference for current contracts, and Known Limitations for verified constraints that may explain unexpected behavior. Limitations are context for investigation, not a commitment to a particular roadmap.

Sourcebackend/src/

Development workflowCopy Anchor Link

This sequence is a practical workflow. Explicit repository requirements are identified above and in the PR guidance below.

1. Inspect the issue or behavior. Reproduce it, read the request path, identify consumers, and agree on scope for non-trivial work.
2. Create a focused branch. From the ElixirV4 root, git switch -c fix/event-validation is an illustrative branch command; choose a name describing your change. The repository recommends <type>/<short-description>.
3. Implement the change. Follow Add or Change an API Endpoint or Change the Database Schema as appropriate. Keep unrelated refactors and dependency upgrades separate.
4. Verify behavior. Exercise success, invalid input, access restrictions, and relevant database cases. CONTRIBUTING.md requests tests for testable code, regression tests for fixes, and a 90%+ coverage target for code requiring tests. There is currently no checked-in backend test suite, test script, or coverage tooling; coordinate that gap with maintainers and report manual evidence accurately.
5. Run available checks. Use the correct package context below. Record commands and outcomes, including existing failures, rather than treating a green optional-test job as backend coverage.
6. Update documentation. Change request/response examples and affected handbook pages. If both repositories need changes, link their PRs and make compatibility requirements explicit.
7. Prepare a PR. Review the full diff, explain the behavior and verification, and keep it in Draft until ready under the repository's contribution instructions.

SourceCONTRIBUTING.md

Project commandsCopy Anchor Link

Use these after installing dependencies in the relevant package. Backend runtime and migration commands also need local configuration; see Quickstart instead of copying production values from env.example.

Backend npm run start is defined as node dist/server.js, but the current TypeScript config does not set that output directory. See Deployment & Configuration before relying on it.

The contribution file also places detailed documentation in /docs and names a public documentation destination. This handbook is maintained in the separate elixir-docs repository; those statements do not establish its deployed state or move these pages into ElixirV4.

Sourcepackage.json

Sourcebackend/package.json

Sourcebackend/tsconfig.json

Source.github/workflows/ci.yml

Pull request expectationsCopy Anchor Link

Make the PR easy to review with a focused diff, a clear description of what changed and why, reproduction steps for a bug, affected consumers, and verification evidence. Include exact commands, manual request outcomes, and known failures. For schema changes, explain the SQL, existing-data compatibility, rollout ordering, and recovery considerations. For UI changes, include useful screenshots or before/after evidence without tokens or private data.

These are practical review recommendations supported by CONTRIBUTING.md. Its explicit instructions include keeping unfinished PRs in Draft, completing self-review and documentation before requesting review, passing CI, and including a Loom walkthrough for code changes when visual or contextual explanation helps. Documentation-only and genuinely minor changes do not require Loom. Do not claim that CI enforces every contribution expectation: the checked-in workflow runs frontend lint/typecheck/build and the backend optional-test command described above.

SourceCONTRIBUTING.md

Where to go nextCopy Anchor Link

• Backend Quickstart — set up and verify a local backend.
• Backend Architecture — trace execution boundaries.
• Add or Change an API Endpoint — change a request contract and verify access.
• Change the Database Schema — review migrations and data compatibility.
• API Reference — find route-specific inputs and responses.
• Known Limitations — account for current behavior and operational uncertainty.