Contributing to Accounts
TL;DR; Tests, coverage, linting, changelog (See Pull Request Requirements, below).
The Accounts project was intended - since its inception - to be a community maintained project. We would love to see you get involved (especially long time contributors from the Meteor community who we've worked with before).
- Fork the project on Github (top right on the project page)
- Clone the project:
git clone email@example.com:yourname/accounts
- Checkout a relevant branch like:
git checkout some-branch
- Create your own feature branch:
git checkout -b proposed-feature
- Install project dependencies:
- Compile the packages
pnpm run compile
- Watch the packages for changes and recompile:
pnpm run start(You need to run this command in the package subfolder you are updating)
docker-compose up -dto start database services required for tests.
pnpm run testto run all the tests.
For non-bug-fixes, please open an issue first and discuss your idea to make sure we're on the same page.
Alternatively, prepend your PR title with
[discuss] to have a conversation around the code.
Must not break the test suite (
pnpm run test), nor reduce test coverage (
pnpm run coverage). If you're fixing a bug, include a test that would fail without your fix.
Must respect the .eslintrc.js (
pnpm run test:lint). Ideally your editor supports
eslint. Especially since the project is quite new, feel free to query default rules with us that don't make sense, or disable rules in a particular scope when it makes sense, together with a comment explaining why.
Must be isolated. Avoid grouping many, unrelated changes in a single PR.
GitHub now allows auto-squashing of commits in a PR, so no need to rebase your commits before final submission.
Must contain a changeset file describing the changes and affected packages. Run
pnpx changesetto generate one.
- From Getting Started, your work should ideally be in its own feature branch.
git pushyour branch to git and create a new pull request for the appropriate branch.
Contributors with Commit Bit
Should still submit a PR for changes (i.e. no work should be done on a branch directly; all work should be done in it's own separate feature branch), which should be okayed by one other team member before merging.
Should squash merged PRs whenever possible (via GitHub options).
We also welcome financial contributions in full transparency on our open collective. Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed.
Thank you to all our backers! [Become a backer]
Thank you to all our sponsors! (please ask your company to also support this open source project by becoming a sponsor)