Source code
Project is using git versioning system is hosted on github.
Clone the repository
git clone https://github.com/intake24/intake24Repository structure
Repository is set as mono-repository with workspaces using pnpm.
Deployable applications are in apps folder. Shared components are in packages folder.
.
├─ .github -> Github actions / workflows
├─ apps -> Applications
│ ├─ api -> API Server
│ ├─ admin -> Admin tool
│ ├─ docs -> Documentation
│ ├─ cli -> Command line interface
│ └─ survey -> Survey application
├─ deployment - Ansible playbooks / scripts for deployment
├─ docker - Docker files for development
└─ packages
├─ api-client-v3 -> API Client (Intake24 V3)
├─ api-client-v4 -> API Client (Intake24 V4 - current)
├─ common -> repository-wide shared code
├─ common-backend -> backend shared code, e.g. services
├─ db -> database layer (models, migrations, etc.)
├─ i18n -> translation files for all applications
└─ ui -> frontend shared code (admin / survey)Dependencies
Project is using pnpm as a package manager.
Install pnpm using corepack or see pnpm docs for further installation options.
corepack enable
corepack installInstall project dependencies from repository root.
pnpm installCommit convention
Commit messages are restricted to follow conventional-changelog convention, adapted from Angular's commit convention.
.github/commit-convention.mdfor more details.scripts/verify-commit.tsfor implementation.
Versioning system
Intake24 uses a hybrid versioning system based on Calendar Versioning (CalVer) and Semantic Versioning (semver).
Version numbers generally follow the Semantic Versioning principles with the following exceptions:
- Major version is the year of the release in YYYY format
- Minor version starts at 1 instead of 0
Format
Version numbers follow the format
YYYY.MINOR.PATCH
where
YYYY is the year of the release using the four-digit format,
MINOR is the sequential number of a feature release in the corresponding year. "Feature release" means a major release adding new features or functionality or significant changes to existing features.
PATCH is the sequential number of a bug fix release. "Bug fix release" means a release focused on fixing issues with existing features without adding new functionality.
Year increments
Bug fix releases are always associated with a specific feature release (i.e., YYYY.MINOR) and the year should never be incremented when releasing bug fix versions, even if a bug fix release occurs in a later year.
Examples
2022.1.0 — first feature release of 2022,
2022.2.3 — third bug fix for the second feature release of 2022,
2022.4.1 — a bug fix release for the final, fourth feature release of 2022 that could be released in 2023.
Pre-release versions
Pre-release versions follow the Semantic Versioning system:
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.
Examples
2022.1.0-beta — initial beta release of the first feature release in 2022,
2022.1.0-beta.4 — fourth update of the 2022.1.0 beta.
Code style
Project is set up with eslint configured with antfu preset to help to keep clean and maintainable code.
ESLint integrates very well with most of the IDEs. Install respective plugins / extensions and configure it to run on save to have immediate effect.
You can also run lint process manually from repository root.
pnpm lintLint step also runs for each staged file, when changes are being committed (using git hooks).
Renovate
Repository is set up with renovate bot, which checks repository for up-to-date dependencies and prepares PRs to be merged. Renovate job runs on weekly basis and can be configured through .github/renovate.json5 config file.
Continuous integration
Build
Main CI action is triggered on any source code change and it runs lint / build / tests / steps for each of the components.
Documentation
Docs CI action is triggered on docs folder source code change and documentation site is automatically rebuilt and deployed to GitHub pages.