If you want to contribute to express-graphql-persisted-queries
, that's really great! To make the process of contributing smooth, here are the guidelines that you should follow:
- Code of Conduct
- Bugs
- Feature requests
- Creating an issue
- Creating a pull request
- Code expectations
- Commit message guidelines
To keep express-graphql-persisted-queries
open and inclusive, please read and follow our Code of Conduct.
If you happen to find a bug in express-graphql-persisted-queries
, you can report it by creating an issue.
When reporting a bug, you should explain in detail how it can be reproduced and show any relevant code. You should also specify the version of express-graphql-persisted-queries
in which the bug occurs.
If you also know how to fix the bug, it would be great if you create a pull request with the fix.
If there's a feature that express-graphql-persisted-queries
is missing and you think that it would be useful to have, you can create an issue with the feature request.
If you want to implement a new feature, here's what you should do:
- If it's a BIG feature, you should first open an issue that describes the new feature so that we can have a discussion around it. Once we found an agreement, you can begin the implementation. When you're done, you should open a pull request with your changes.
- If it's a small feature, you can directly open a pull request with your changes.
If you want to create an issue, you should first search the existing open/close issues to see if there's already an issue for the problem you have or the feature you want to request. In that case, you can read the discussion and contribute to it.
Once you checked that there is no existing issue for your problem or feature request, you can create an issue by filling this form.
Here are the steps you should follow to create a pull request:
-
Search the existing open/close pull requests to see if there's already been an effort related to the changes you want to make. If there is, and it is still open or it was closed without merging, it probably makes little sense to create a duplicate PR.
-
Fork the
kyarik/express-graphql-persisted-queries
repository. -
Clone the forked repository locally.
-
Go to the repo directory and run
npm install
. -
Keep your
main
branch pointing at themain
branch in thekyarik/express-graphql-persisted-queries
repository:git remote add upstream https://github.com/kyarik/express-graphql-persisted-queries git fetch upstream git branch --set-upstream-to=upstream/main main
This adds the original repository as a
remote
calledupstream
, fetches git info fromupstream
, and sets your localmain
branch to use theupstream/main
branch whenever you rungit pull
. -
Create a branch from
main
in which you will make your changes:git checkout -b your-branch-name main
-
Make your changes along with tests.
-
Make sure to follow the code expectations.
-
Run all checks:
npm run checks
-
Commit your changes following the commit message guidelines.
-
Push your branch to GitHub:
git push origin your-branch-name
-
Using the GitHub UI, create a pull request towards the
express-graphql-persisted-queries:main
branch. If we request changes in the PR, then:- Make the requested changes.
- Re-run the checks.
- Push your changes.
Thank you for contributing to express-graphql-persisted-queries
!
There are some expectation that we have over the code in this repository, so please follow them:
- Write tests for every new feature or bug fix.
- Every change to the public API should be documented in the README as well as in the source code by using TSDoc.
Commit messages should follow the Conventional Commits specification.
The allowed commit types are based on the Angular convention:
- build: Changes that affect the build system or dependencies
- ci: Changes to our CI configuration files and scripts
- docs: Documentation only changes
- feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
- test: Adding missing tests or correcting existing tests
Here's an example commit message:
fix: make max buffer size refer to byte length not string length
If a commit reverts a previous commit, it should start with revert:
, followed by the header of the reverted commit. The body of the commit should say This reverts commit <HASH>
, where <HASH>
is the SHA of the commit being reverted. Example:
revert: build: update dev dependencies
This reverts commit 4259fb7cdae915ac529f5b89a92f059391aff43b