If you're seeing this document, you are an early contributor to the development and success of XMTP. We welcome your questions, feedback, suggestions, and code contributions.
Have a question? We welcome you to ask it in Q&A discussions.
Bugs should be reported as GitHub Issues. Please confirm there isn't already an open issue and include detailed steps to reproduce.
These should also be submitted as GitHub Issues. Again, please confirm there isn't already an open issue. Let us know what use cases this feature would unlock so that we can investigate and prioritize.
PRs are encouraged, but we suggest starting with a Feature Request to temperature-check first. If the PR would involve a major change to the protocol, it should be fleshed out as an XMTP Improvement Proposal before work begins.
Please add unit tests for your feature, and ensure that all unit tests are passing before submitting a pull request. All test commands are described in package.json and executed via npm run <command>. Note that the unit tests require a backend node to be running locally - the test:setup step can be run a single time to start the node in the background, and test can be run as many times as desired afterwards.
Manual validation requires setting up a client app such as the example app. Once you have cloned and run the example app, it will use a published npm version of xmtp-js by default. You can point it to your local xmtp-js repository by running npm i file:~/path/to/xmtp-js from the example-chat-react directory, which will update its package.json. Once the example app is running, any further changes you make to xmtp-js will be reflected in the app after you run npm build in the xmtp-js directory and then reload the app.
After a pull request is submitted, a single approval is required to merge it.
A new version of this package will be automatically published whenever there is a merge to the main branch. Specifically, new GitHub releases and tags will be created, and a new NPM package version will be published. The release version increment type is derived from the format of the commit messages that were bundled in the merge to main, using semantic-release commit message conventions.
The table below shows example commits and the resulting release type for a pencil project:
| Commit message | Release type |
|---|---|
docs: describe scribble feature |
No Release |
test: fix failing unit test |
No Release |
fix: stop graphite breaking when too much pressure applied |
|
feat: add 'graphiteWidth' option |
|
perf: remove graphiteWidth optionBREAKING CHANGE: The graphiteWidth option has been removed.The default graphite width of 10mm is always used for performance reasons. |
(Note that the BREAKING CHANGE: token must be in the footer of the commit) |
This is currently configured to use the Angular Commit Message Conventions. e.g. feat: add message signing would cause a minor release.
If there are multiple commits within a single pull request, each commit will be listed as a separate bullet point in the release notes and bundled together in a release of the highest increment type specified.
If your commit messages are not to your liking, it is permitted to rewrite the history on your branch and force-push it before merging it. Make sure you are never force-pushing on main, and that the following is in your ~/.gitconfig file.
[push]
default = simple
Please make sure you have a Node version compatible with that specified in the root .nvmrc file. We recommend using nvm to manage local node versions - find install instructions appropriate for your system here.
You will need to install Buf in your environment in order to npm build this package from source.
brew install bufbuild/buf/buf