The community server is fully written in Typescript.
All changes should be done through pull requests.
We recommend first discussing a possible solution in the relevant issue to reduce the amount of changes that will be requested.
In case any of your changes are breaking, make sure you target the next major branch (
instead of the main branch. Breaking changes include: changing interface/class signatures,
potentially breaking external custom configurations,
and breaking how internal data is stored.
In case of doubt you probably want to target the next major branch.
We make use of Conventional Commits.
Don't forget to update the release notes when adding new major features. Also update any relevant documentation in case this is needed.
When making changes to a pull request, we prefer to update the existing commits with a rebase instead of appending new commits, this way the PR can be rebased directly onto the target branch instead of needing to be squashed.
There are strict requirements from the linter and the test coverage before a PR is valid. These are configured to run automatically when trying to commit to git. Although there are no tests for it (yet), we strongly advice documenting with TSdoc.
If a list of entries is alphabetically sorted, such as index.ts, make sure it stays that way.