Dansdata is a project by dancers, for dancers. Contributions are welcome!
All code should be formatted with npm run format
.
If you are adding a new language to the repository, please extend the npm run format
command as well as .lintstagedrc
with an appropriate formatter.
Opinionated formatters are preferred to ensure consistency.
The Dansdata project strives for a readable git history. Branches are therefore merged using the rebase strategy. This preserves each individual commit, making changes to individual lines easier to follow and history entries smaller.
PRs should be created from/to the develop
branch.
Every commit should strive to do one thing and one thing only, whether that be reformat code, remove unused imports or implementing new functionality. Please keep your commits as small as possible and separate unrelated changes from each other.
Commit messages must follow the conventional
config and will be validated using commitlint
. See also
https://www.conventionalcommits.org/ .
When working on a specific issue, the issue id should be used as the scope, e.g.
fix(API-123): something related to issue API-123
.
There are times when a single-line commit is warranted but it is preferred to err on the side of verbosity. Please try to include the following information in your commits:
- Why this change was necessary
- What the change does
- Known issues with the solution
- Other relevant information
To make review work easier, pull requests are requested to use fixup
commits
to address comments.
If you need to update your commit messages, squash
commits can be a good way to make such
intentions clear in a similar way to fixup
commits.
abcd123 feature(123): feature A is done
1234abc feature(123): feature B is done
Please correct this spelling error
---
Please remove this unused import
---
...
Repeat for each comment - please use one fixup per comment to make reviews easier.
git commit --fixup abcd123
# Change message from
# ```
# fixup! feature(API-123): feature A is done
# ```
# to
# ```
# fixup! feature(API-123): feature A is done
#
# Change langage -> language
# ```
# This helps reviewers know which comment is addressed by the fixup
# (This part is optional - but helpful)
git commit --amend
abcd123 feature(API-123): feature A is done
1234abc feature(API-123): feature B is done
efgh123 fixup! feature(API-123): feature A is done
qwer123 fixup! feature(API-123): feature B is done
zxcv123 fixup! feature(API-123): feature A is done
Reviewed fixups may be integrated with the commit they are targeting using
git rebase -i (--autosquash)
All fixups must be integrated with their target commit before the PR branch is merged. You
will need to use git push -f
to update your PR branch after performing this history
rewrite.
When addressing issues raised for a fixup, your new fixups should still target the original commit.
i.e. do this:
abcd123 feature(API-123): feature A is done
efgh123 fixup! feature(API-123): feature A is done
ijkl123 fixup! feature(API-123): feature A is done
not this:
abcd123 feature(API-123): feature A is done
efgh123 fixup! feature(API-123): feature A is done
ijkl123 fixup! fixup! feature(API-123): feature A is done