We are open and grateful for any contribution made by the community. If you're interested in contributing to AgileTs, this document might make the process for you easier.
The Open Source Guides website has a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. Contributors and people new to open source will find the following guides especially useful:
Please read the full text, so that you are able to understand what interpersonal actions will and will not be tolerated.
There are many ways to contribute to AgileTs, and some of them don't involve writing any code. Here are a few ideas to get started:
- Just start using AgileTs. Does everything work as expected? If not, we're always looking for improvements. Let us know by opening an issue.
- Help us solving open issues by suggesting workarounds or fixing them.
- Improve open issues to make them more clear, readable and understandable for others.
- Read through the AgileTs docs. If you find anything that is confusing or can be improved, feel free to make edits by clicking "Edit" at the bottom of the doc page.
- Take a look at the features requested by others and consider opening a pull request if you see something you want to work on.
Contributions are very welcome and not bound to github. You can also contribute in our Discord Community by helping other people which might face a problem you already have solved.
One great way to contribute without writing any code is to improve open issues and pull requests.
- Ask for more information if you believe the issue does not provide all the details required to solve it
- Suggest labels that help to categorize issues/pull-requests
- Flag issues that are stale or that should be closed
AgileTs uses Github as it's source of truth. All changes made so far and which will be made in future are and will remain publicly accessible here.
AgileTs has two primary branches:
master contains the latest released code
develop is where development takes place
The root of all your branches have to be the
We use GitHub Issues to keep track of our bugs. If you would like to report any problem, take a look around and see if someone already opened an issue about it. If you are certain this is a new unreported bug, you can submit a bug report.
When opening a new issue, always make sure to fill out the whole issue template. This step is very important! Not doing so may result in your issue not managed in a timely fashion. Don't take this personally if this happens, and feel free to open a new issue once you've gathered all the information required by the template.
- One issue, one bug! Please report a single bug per issue.
- Provide reproduction steps! List all steps that are necessary to reproduce the issue. The person reading your bug report should be able to reproduce your issue with minimal effort.
- Ensure you have Yarn installed
- After cloning the repository, run
yarn run install-packagesin the root of the repository, which simply runs
yarn installin each package to ensure all dependencies are installed.
- Follow the Installation steps above
- Ensure you have Yalc installed
yarn run dev-publishto publish all packages in your local 'npm store'
yarn installin the Example Project to install its dependencies like AgileTs
- If you made your desired changes. Run
yarn run dev-pushto push your updated changes into your local 'npm store'
ProTip: To make realtime changes, run
yarn run watch, which automatically runs
yarn run dev-pusheverytime you update a file in a package.
So you have also decided to merge code back to the upstream by opening a PR. You've invested a good chunk of time, and we appreciate it. We will do our best to work with you and get the PR looked at.
Working on your first Pull Request? You can learn how, from this free video series:
We have a list of beginner friendly issues to help you to get your feet wet in the AgileTs codebase and familiar with our contribution process. This is a great place to get started.
If you would like to request a new feature or enhancement but you only want to give an impulse and don't want to implement it, feel free to create an issue that follows the feature template.
If you're only fixing a bug, it's fine to submit a pull request right away, but we still recommend creating an issue detailing what you're fixing. This is helpful in case we don't accept that specific changes, but want to keep track of the issue.
Keep in mind that small pull requests are much easier to review and more likely to get merged. Make sure your PR only solves one problem (issue), otherwise please split it up in multiple PR's for a better overview. Commit Messages that follow this style guide are very welcome ^^
Please make sure the following is done before submitting a new pull request:
- Fork the repository and create your branch from
- Make sure your code is right formatted (
- Make sure all Jest tests pass (
- Don't forget the How has this been Tested? part!
All pull requests should be opened against the
and have a related Issue for better organization!
When adding a new breaking change, follow this template in your pull request:
The core Team of AgileTs is constantly monitoring pull requests and merges them if they seem correct. Help us to keep pull requests consistent by following the guidelines above.
Prettier will catch most styling issues that may exist in your code.
You can check the status of your code styling by simply running
Most important: Look around. Match the style you see used in the rest of the project(formatting, naming, ..).
By contributing to AgileTs, you agree that your contributions will be licensed under its MIT license.
This File is inspired by the Docusaurus CONTRIBUTING.md.