Code Quality

CI Pipelines

Continuous Integration (CI) pipelines ensure code quality by automating build, test, and deployment processes.
Our CI setup includes the following key steps:

• Build and dependency installation – Ensures the project compiles and all dependencies are correctly installed.
• Linting and static analysis – Validates code style and detects potential issues before merging.
• Unit and integration tests – Runs tests and collects code coverage reports.
• Deployment – Automates deployment to staging and production environments.

CI pipelines are configured using GitHub Actions and are triggered on:

• Every push to main.
• Every pull request.

Pipeline execution results are available in the GitHub Actions tab.

Husky scripts

We use Husky to enforce code quality rules at the commit level. Pre-commit hooks ensure that:

• Code passes linting before being committed.
• Tests are run when necessary.
• No code with failing checks is pushed.

Developers should install Husky locally by running:

npm run prepare

This ensures hooks are correctly set up in local development.

Lints

Code quality is enforced through ESLint and Prettier.

• ESLint checks for potential issues and enforces coding standards.
• Prettier ensures consistent formatting across the codebase.
• Stylelint is used for maintaining CSS/SASS best practices.

Linting is automatically run in CI as part of every pull request and push to main.

Developers should also run lint checks locally:

npm run lint

Fixable issues can be automatically corrected with:

npm run lint:fix

Type safety

We use TypeScript to ensure type safety across the codebase.

• Strict mode is enabled for maximum type safety.
• Type definitions are checked in CI.
• Developers should use type annotations where applicable to prevent runtime errors.

To check type correctness locally, run:

npm run type-check

Code Review and PRs

Code changes go through a structured Pull Request (PR) review process before merging.

• Every PR requires at least one approval.
• Code should be properly linted and tested before submission.
• Meaningful commit messages and PR descriptions are required.
• If a PR introduces significant changes, related documentation should be updated accordingly.

Best practices for PRs:

• Keep PRs small and focused to ease the review process.
• Provide clear descriptions of the changes and their impact.
• Link to related issues or discussions if applicable.
• Request reviews from relevant team members.