We would love for you to contribute to the TALY codebase! As a contributor, here are the guidelines we would like you to follow:
Please look at the list of open/closed issues and discussions. If you didn't find an answer to your question, please open a GitHub discussion.
If you find a bug in TALY or a mistake in the documentation, you can help us by submitting a bug report to our GitHub Repository. Even better, you can submit a Pull Request with a fix.
You can request a new feature by submitting a feature request to our GitHub Repository.
We appreciate very much if you are willing to implement the feature. In that case, please wait for us to discuss your feature request and accept it. This process allows us to better coordinate our efforts, keep a healthy codebase and a meaningful set of features, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
Source code and documentation are included in the top-level folders listed below:
additional-documentation - Markdown and asset files for documentationapps/playground - application which is a live example of a TALY-generated journeyci - CI/CD pipelineslibs - Source code for the different TALY librariestools - Miscellaneous scripts for project tasks such as building documentation, generating schemas or publishing.npm installnpx nx build LIB_NAME, e.g. npx nx build nxnpx nx test LIB_NAME, e.g. npx nx test nxnpx nx develop playgroundnpm run docs:developBefore doing any submission, please search the issue tracker and the discussions. An issue or discussion for your problem may already exist and has been resolved, or a comment in them might inform you of workarounds readily available.
We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. Having a reproducible scenario gives us a wealth of important information without going back and forth with you requiring additional information. A minimal reproduction allows us to quickly confirm a bug (or point out a coding problem) as well as confirm that we are fixing the right problem.
We will be insisting on a minimal reproduction in order to save maintainers' time and ultimately be able to fix more bugs. Interestingly, from our experience, users often find coding problems themselves while preparing a minimal reproduction repository. We understand that sometimes it might be hard to extract essentials bits of code from a larger codebase, but we really need to isolate the problem before we can fix it.
You can file a new bug report by filling out the corresponding template in our issue form.
When proposing a new feature, please make sure you are making your point very clear. We need to understand the use case, the problem it solves, and the general approach you have in mind to solve it.
To file a feature request, please fill out the dedicated template in our issue form.
Before submitting a PR please make sure your code changes are ready to be reviewed by checking the following:
npx jest --help or visit jestjs.ioWhen submitting a PR (here), please make sure to fill out the template completely. The template is there to help you and to make sure you don't forget anything.
After a PR is merged to the main branch, a new beta version will be automatically released. You can use that version to try out your changes in your own project. To find out the version number, you can run either this command: npm info @allianz/LIB_NAME@next version (e.g. npm info @allianz/taly-nx@next version), or check if there is a release commit after your PR merge commit in the main branch in the taly-workspace repo: git log -n 2 --oneline
If your PR provides a breaking change, do the following:
Add ! after the type in the PR title to indicate that the PR contains breaking changes (e.g., feat!: breaking change feature)
Provide a proposal for the breaking change message in the PR description, so that it can also be reviewed. This message will be used in the release notes.
If you are the one eventually merging the PR, make sure to add the breaking change message to the merge commit, via the GitHub UI. For example:
feat!: breaking change feature
BREAKING CHANGE: Here the message with markdown formattingYou can find the official docs about this topic in the conventional commits docs (here).
If your PR provides a deprecation, do the following:
Provide a proposal for the deprecation message in the PR description, so that it can also be reviewed. This message will be used in the release notes.
If you are the one eventually merging the PR, make sure to add the deprecation message to the merge commit, via the GitHub UI. For example:
feat(@allianz/taly-nx): a PR that deprecates something
DEPRECATION: Here the message with markdown formattingDue to the limitations of the CHANGELOG generator, if the commit contains multiple footers e.g., breaking changes and deprecations, the deprecations must be placed before the breaking changes. For example:
DEPRECATION: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>We enforce conventional commits with @commitlint/config-conventional.
The commit scope would be in most cases the name of a TALY library: nx, acl, etc. A commit hook will transform the scope from e.g. nx to @allianz/taly-nx. You shall write commit messages like this:
docs(acl): add more information about the ACL conditions
// Changes in several TALY libraries, but the most relevant changes happened in `taly-nx`
feat(nx): provide a new service to monitor scrolling
// no scope when commit not applicable to a concrete TALY library
fix: downgrade rxjs to prevent an error with the current Angular versionProvide additional information about the commit in the body of the message, if needed.
Ensure to mark deprecations and breaking changes with the appropriate notice in the commit footer.