Welcome, so you are thinking about contributing to PouchDB? Awesome, this is a great place to start.
The following documentation should answer most of the common questions about how to get starting contributing, if you have any questions, please feel free to get in touch @ the Google Groups mailing list, and on StackOverflow. Or you can tweet @pouchdb.
Most project discussions should happen on the Mailing list / Bug Tracker, however if you are a first time contributor and want some help getting started feel free to send a private email to any of the following maintainers:
If you are looking for something to work on, we try to maintain a list of issues that should be suitable for first time contributions, they can be found tagged help-wanted.
Bugs that get filed have no labels and are triaged. A bug should be given one of the following labels: bug, enhancement, needs-reproducing, question during triage. Issues with the bug label will not be marked stale.
(#99) - A brief one line description < 50 chars Followed by further explanation if needed, this should be wrapped at around 72 characters. Most commits should reference an existing issue
PouchDB needs the following to be able to build and test your build, if you haven't installed them then best to do so now, we will wait.
On Windows? PouchDB's build and tests work on Windows, but you will have to follow Microsoft's guidelines for Windows to ensure you can install and compile native add-ons. Also, we recommend Git Bash for Windows because our build relies on many Bash- and Unix-isms. Another option is Windows Subsystem for Linux.
All dependencies installed? Great, now building PouchDB itself is a breeze:
$ cd pouchdb $ npm install $ npm run build
You will now have various distributions of PouchDB in your dist folder, congratulations.
Note that the source code is in src/, which is built by Rollup as a Node module to lib/, which is then built by Browserify as a browser-ready UMD module to dist/. All of this logic is in bin/build.sh.
The main PouchDB test suite can be run with:
$ npm test
If you would like to test against your a CouchDB instance you are currently running you can specify that with COUCH_HOST:
$ COUCH_HOST="http://127.0.0.1:5984" npm test
There is more information about the various test suites and testing options in TESTING.
Workflows can vary, but here is a very simple workflow for contributing a bug fix:
$ git clone https://github.com/pouchdb/pouchdb.git $ git checkout -b 121-issue-keyword master # Write tests + code $ git add src/afile.js $ git commit -m "(#121) - A brief description of what I changed"
Once you have some code to push, fork the PouchDB repository then push your changes to your fork:
$ git remote add myfork https://github.com/myfork/pouchdb.git $ git push origin 121-issue-keyword
Now when you visit https://github.com/myfork/pouchdb there should be a button that will let you create a pull request.
The source for the website http://pouchdb.com is stored inside the docs directory of the PouchDB repository, you can make changes and submit pull requests as with any other patch. To build and view the website locally you will need to have the Ruby development package installed. On Ubuntu this is done with:
$ sudo apt install -y ruby-dev
You then neet to install jekyll and a few other gems. Jekyll is installed using bundler so you need to install that first. On Ubuntu you will need root permissions to do this so prefix the gem command with sudo
$ [sudo] gem install bundler $ npm run install-jekyll
If you haven‘t already done so, you’ll also need to run npm install to pull in packages for the dev server:
$ npm install
Now you can build the site and start the dev server with:
$ npm run build-site
You should now find the documentation at http://127.0.0.1:4000
Writing a blog post for PouchDB is exactly the same process as other contributions; all the blog posts are kept at https://github.com/pouchdb/pouchdb/tree/master/docs/_posts. We always welcome blog posts from new contributors!
npm run build-site and you will always have a fresh version of the site at localhost:4000. You may need to Cmd-Shift-R or Ctrl-Shift-R (hard refresh) to see the latest version, since we use AppCache.With great power comes great responsibility yada yada yada:
tin -v x.x.x-prerelease with x.x.x being the previous version upgraded appropriately via semver. When we are ready to publish to npm we can remove the -prerelease.How to merge a pull request
curl https://patch-diff.githubusercontent.com/raw/pouchdb/pouchdb/pull/[PATCH NUMBER].patch | git am - && git push origin master, replacing [PATCH NUMBER] with the number of the patch you want to merge.npm run set-version -- $VERSIONnpm run release. Note that with 2FA in npm, it will request you an OTP for every package.dist/pouchdb* files from the $VERSION tag on github, paste the release notes and add the distribution files to Github Releases, rename pouchdb.min.js to pouchdb-$VERSION.min.js (same with pouchdb.js) after you upload it.npm run publish-siteTo do a dry run release, you can run:
DRY_RUN=1 npm run release
To do a beta release to npm (using the dist-tag beta), do:
BETA=1 npm run release