- The DEVELOPING doc has details on how to set up your environment.
- Familiarize yourself with the codebase by reading the docs, which you can generate locally by running
yarn docs
. - Create a new issue before starting your project so that we can keep track of what you are trying to add/fix. That way, we can also offer suggestions or let you know if there is already an effort in progress.
- Fork this repository (external contributors) or branch off main (committers).
- Create a topic branch in your fork based on the main branch. Note, this step is recommended but technically not required if contributing using a fork.
- Edit the code in your fork/branch.
- Write appropriate tests for your changes. Try to achieve at least 95% code coverage on any new code. No pull request will be accepted without associated tests.
- Sign CLA (see CLA below).
- Send us a pull request when you are done. We'll review your code, suggest any needed changes, and merge it in.
- Upon merge, a new release of the
@salesforce/packaging
library will be published to npmjs with a version bump corresponding to commitizen rules.
External contributors will be required to sign a Contributor's License Agreement. You can do so by going to https://cla.salesforce.com/sign-cla.
- We work in branches off of
main
. - Our released (aka. production) branch is
main
. - Our work happens in topic branches (feature and/or bug-fix).
- feature as well as bug-fix branches are based on
main
- branches should be kept up-to-date using
rebase
- commit messages are enforced
- feature as well as bug-fix branches are based on
- Develop features and bug fixes in topic branches off main, or forks.
- Topic branches can live in forks (external contributors) or within this repository (committers).
** When creating topic branches in this repository please prefix with<initials>/
. - PRs will be reviewed and merged by committers.
- A new version of this library (
@salesforce/packaging
) will be published upon merging PRs tomain
, with the version number increment based on commitizen rules. E.g., if any commit message begins with, "feat:" the minor version will be bumped. If any commit message begins with, "fix:" the patch version will be bumped.