First off, thank you for considering contributing to Movex. It's people like you that make a difference in open source. By contributing to Movex, you agree to abide by the Code of Conduct.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
Movex is an open-source project and we love to receive contributions from our community — you!
Here are some ways you can contribute:
- Try building or deploying Movex and give feedback. You can follow this Get Started tutorial for an intro!
- Add new framework wrappers (e.g. libs/movex-vue, libs/movex-angular, etc.)
- Help with open issues or create your own
- Share your thoughts and suggestions with us
- Help create tutorials and blog posts
- Request a feature by submitting a proposal
- Report a bug
- Improve documentation - fix incomplete or missing docs, bad wording, examples or explanations.
- If you're making changes to the Movex core, ensure it runs correctly both on client AND server
- Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
- Ensure all regression tests are passing after your change
- Keep feature versions as small as possible, preferably one new feature per version.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds.
This is very important so github can trace your contribution correctly, and avoid the following merging block message:
Please follow this guide to learn more about signing commits.
Unsure where to begin contributing to Movex? You can start by looking through the good-fist-issue and help-wanted issues:
- Good first issues - issues which should only require a few lines of code, and a test or two.
- Help wanted issues - issues which should be a bit more involved than beginner issues.
Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub
Important: The project is a monorepo, meaning that it is a collection of multiple packages managed in the same repository.
These packages are located at /libs and they are the following:
- movex (the movex core)
- movex-core-utils (utility functions shared between each library)
- movex-service (the CLI tool, able to start movex in dev and built it for production)
- movex-server (the node backend running on the server)
- movex-react (the react wrapper)
Based on the issue you're working on, one or more of these libraries will be touched.
Visit the issue tracker to find a list of open issues that need attention.
Fork, then clone the repo:
git clone https://github.com/your-username/movex.git
This repo uses Yarn for all package management.
When working on a library in /libs there is no need to build anything!
yarn test
To continuously watch and run tests, run the following:
yarn test --watch
Alternatively, to skip the nx caches you can run:
yarn test --watch -- --skip-nx-cache
This repo uses commitizen to keep the commits structured and tidy.
To commit run the following:
yarn commit
Optionally, if you'd like to keep running git commit you can configure the git hooks as in this tutorial.
For non-trivial changes, please open an issue with a proposal for a new feature or refactoring before starting on the work. We don't want you to waste your efforts on a pull request that we won't want to accept.
In general, the contribution workflow looks like this:
- Open a new issue in the Issue tracker.
- Fork the repo.
- Create a new feature branch based off the master branch.
- Make sure all tests pass and there are no linting errors.
- Submit a pull request, referencing any issues it addresses. See Opening New PR Requirements
- Please try to keep your pull request focused in scope and avoid including unrelated commits.
- A Pull Request always refers to an Open Issue.
- The Title of a Pull Request should look like '{ADD|FIX|REFACTOR|REVERT} "[{Issue Scope}]{Issue Title} #{Issue Id}"'.
- Reference the Issue it addresses in the Description of the PR by its Id, so when the PR gets merged the Issue gets closed automatically
Example:
The PR Title for this Issue:
looks like:
After you have submitted your pull request, we'll try to get back to you as soon as possible. We may suggest some changes or improvements.