Thanks for taking the time to help out and improve Drizzle! 🎉
The following is a set of guidelines for Drizzle contributions and may change over time. Feel free to suggest improvements to this document in a pull request!
All contributions are welcome!
If you run into an issue, the first step is to reach out in our community Gitter channel, in case others have run into the problem or know how to help.
To report a problem or to suggest a new feature, open a GitHub Issue. This will help the Drizzle maintainers become aware of the problem and prioritize a fix.
For code contributions, for either new features or bug fixes, see Development.
If you're looking to make a substantial change, you may want to reach out first to give us a heads up.
Drizzle has two companion libraries (drizzle-react and drizzle-react-components), each with their own NPM packages.
The content of this guide applies to those companion libraries as well.
This repository (trufflesuite/drizzle) contains the core logic for storing and updating chaindata in a Redux store.
In order to develop Drizzle, you'll need:
First clone this repository and install NPM dependencies:
$ git clone [email protected]:trufflesuite/drizzle.git
$ cd drizzle
$ npm install
$ npm test
If all is good, then run the build command :
$ npm run build
Your local Drizzle copy is contained in the dist/ directory.
To use this in a project, use npm link:
$ cd dist
$ npm link // may require sudo
$ cd my-project-root
$ npm link drizzle
You're ready to use your local development version of Drizzle in your project.
Community contributions to Drizzle require that you first fork each repository you wish to modify. After your modifications, push changes to your fork(s) and submit a pull request upstream to trufflesuite's fork(s).
See GitHub documentation about Collaborating with issues and pull requests for more information.
❗ Note: Drizzle development uses a long-lived
developbranch for new (non-hotfix) development. Pull Requests should be opened againstdevelopin all repositories.
Drizzle projects adhere to Gitflow, a Git workflow designed around a strict branching model to more easily track feature development vs. releases. For more information on Gitflow, check out Atlassian's helpful guide.
We can separate our branches into long-lived and purposeful branches. We have two long-lived branches:
master, checkout for hotfix development; in sync with the latestrelease(synced after the release has gone out publicly).develop, checkout for feature development; latest unstable releases and work targeting the next major or minor release.
All development is done on branches with a prefix/title style naming convention. These are later merged into develop and finally a release branch before final release. These are the two prefixes we use:
feature/, for new feature development; later merged withdevelopandrelease.fix/, for hotfix development; later merged withmasteranddevelop.
For example, a fix for a contract fetching error might look like: fix/contract-fetching.
Use a branch for your modifications, tracking it on your fork:
$ git checkout -b feature/sweet-feature // or "fix/" prefix if a hotfix
$ git push -u ChocolateLover feature/sweet-feature
Then, make changes and commit as usual.
Join the chat in our community Gitter channel. If anything about this process is unclear, or for helpful feedback of any kind, we'd love to hear from you!
Thanks again for all your support, encouragement, and effort! Drizzle would not be possible without contributors like you. 🙇