Mirroristas/CommunitySolidServer
2
0
Fork 0
mirror of https://github.com/CommunitySolidServer/CommunitySolidServer.git synced 2024-10-03 14:55:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
CommunitySolidServer/documentation/markdown/contributing/making-changes.md
Jasper Vaneessen 9a5fc674f3
style: Enforce linting rules on markdown files 
* chore: add markdownlint-cli2 and config for mkdocs

* style: enforce linting rules on mkdocs md files

* chore: tweaks to markdownlint rules

* style: linting changelog

* style: linting release notes

* style: linting .github md files

* style: further linting of docs

* style: linting readmes

* chore: update linting script entries

* docs: tweak release after rebase

* chore: simplify root md linting config

* chore: extend base config

* chore: implement requested changes

* chore: remove unnecessary exception

* chore: fix comment type

* styling: single config + list spacing

* chore: implement requested changes

* chore: use .cjs files for markdownlint config

* chore: implement requested changes
2022-08-25 11:32:09 +02:00

1.7 KiB
Raw Blame History

Pull requests

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 (versions/x.0.0) 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.