Contributing to Sync-in

March 8, 2026 · View on GitHub

We appreciate your contributions and efforts in making this project better.
Before you contribute, please read the following guidelines to ensure a smooth collaboration.

Code of Conduct

All contributors must follow our Code of Conduct to ensure a friendly and inclusive environment.

How to Contribute

Reporting Issues & Suggesting Features

Bugs

  • Check existing issues before opening a new one.
  • Include detailed steps, logs, and screenshots when possible.

Feature Requests

  • Describe the problem the feature solves.
  • Provide use cases and, if possible, implementation suggestions.

Submitting Pull Requests

  • Open an issue before submitting any pull request for a new feature or bug fix to avoid duplicate work, ensure alignment with the project’s goals, and prevent wasted effort.
  • All pull requests must target the main branch, following the GitHub Flow model with continuous deployment.
  • Make sure your work fits with the existing architecture, code style, and documentation standards.
  • All contributions must comply with the CLA.
  • Contributions are made under the AGPL-3.0 license, the same license used by the project.

Submission Guidelines

  • Keep pull requests small and focused; avoid addressing multiple unrelated issues in a single PR.
  • Ensure all CI checks pass before submitting (linting, type checking, tests, and build).
  • Reference the related issue number in the PR description when applicable.
  • Include tests and update documentation as needed when introducing new features.
  • The PR author is responsible for resolving merge conflicts.
  • Use the Conventional Commits specification for commit messages; pull requests are squashed on merge.

Branching

  • Main: Production branch; all pull requests must target main.
  • Feature branches: Create a dedicated branch per feature or fix and submit a PR to main.

Development Setup

You will need the following on your system:

  • Git
  • Node.js with npm
  • Database server (mariadb)
  • Docker (optional but highly recommended)

Project Structure

The project uses npm workspaces to manage a monorepo with two main workspaces: backend and frontend. This structure enables shared tooling, coordinated builds, and simplified dependency management.

WorkspacePathTechnologyPurpose
Root/npm workspacesMonorepo orchestration, shared scripts
Backend/backendNestJS + FastifyAPI server, business logic, data access
Frontend/frontendAngularUser interface, client-side logic

Setup Instructions

Clone the repo

git clone git@github.com:Sync-in/server.git
cd server

Run the database server

Quick and simple example with docker:

sudo docker run -it -e MARIADB_DATABASE=database -e MARIADB_ROOT_PASSWORD=MySQLRootPassword -p 3306:3306 mariadb:11

Create and edit your environment file

cp environment/environment.dist.yaml environment/environment.yaml

Caution

The mysql.url in the environment.yaml should match the mariadb credentials and the applications.files.dataPath path should be writable.

Install dependencies and build the backend

npm ci
npm -w backend run build

Tip

Building the backend once is useful to generate the script used in the next step (in the dist directory).

Init the database and create the admin user

npx drizzle-kit migrate --config=backend/src/infrastructure/database/configuration.ts
node dist/server/infrastructure/database/scripts/create-user.js --role admin --login admin --password admin

Build the frontend (dev mode)

npm -w frontend run build:dev

Start the backend (dev mode)

npm -w backend run start:dev

Default endpoint is http://localhost:8080, you should be able to login with admin:admin

Happy coding!

Useful Scripts

In the root workspace

  • npm run test run unit tests
  • npm run lint code linting
  • npm run docker:build build the Docker image

Development Guidelines

  • Always write/review tests for new features and bug fixes
  • Follow code style rules (eslint.config.mjs, .prettierrc)
  • Prefer clear naming and documentation within your code
  • Document significant architectural changes and updates

i18n Translations

All translation files follow the same structure:

  • Key: the original text in English (used as the reference in the code)
  • Value: the translated text in the target language

Translation Locations

Translations must be added or updated in the following directories.

Backend

Used for notifications and emails.

To declare a new language:

  1. Edit backend/src/common/i18n.ts and add the language code to the LANG_SUPPORTED constant.
  2. Create a new language file in backend/src/applications/notifications/i18n/ named language_region.ts (lowercase, with an underscore separating the region).
  3. Import the new file in backend/src/applications/notifications/i18n/index.ts, like the other languages, and add it to the translations variable.

Frontend

Used for the web user interface.

To declare a new language:

  1. Edit frontend/src/i18n/l10n.ts and add the language code and language name to the i18nLanguageText variable.
  2. Create a new language file in frontend/src/i18n named language-region.json, using the same language code declared previously.
  3. Import the ngx-bootstrap locale in frontend/src/i18n/lib/bs.i18n.ts. Check if the locale exists in:
    https://github.com/valor-software/ngx-bootstrap/tree/development/src/chronos/i18n
  4. Import day.js locale in frontend/src/i18n/lib/dayjs.i18n.ts. Check if the locale exists in:
    https://github.com/iamkun/dayjs/tree/dev/src/locale

Tip

English is the default language used in the codebase.
Since translation keys are written in English, the English translation file may be missing or incomplete. This is expected.
Any other translation file can be used as a reference for the structure.

Troubleshooting

  • Backend: Check API logs for errors. Use your browser to test endpoints.
  • Frontend: Use Angular DevTools for debugging. Check browser console for runtime errors.
  • Make sure both the server and the database are running.

Thanks again for helping make Sync-in better! 🚀