Thank you for considering contributing to this repo! Community contributions like yours are key to the development and adoption of XMTP. Your questions, feedback, suggestions, and code contributions are welcome!
Have a question about how to build with XMTP? Ask your question and learn with the community in the XMTP Community Forums.
Report a bug using GitHub Issues.
Request a feature using GitHub Issues.
PRs are encouraged, but consider starting with a feature request to temperature-check first. If the PR involves a major change to the protocol, the work should be fleshed out as an XMTP Improvement Proposal before work begins.
After a pull request is submitted, a single approval is required to merge it.
Please make sure you have a compatible version as specified in package.json. We recommend using a Node version manager such as nvm or nodenv.
This repository uses the Yarn package manager. To use it, enable Corepack, if it isn't already, by running corepack enable.
yarn: Installs all dependenciesyarn bench: Run the benchmarking suiteyarn build: Builds the JS SDKyarn format: Run prettier format and write changesyarn format:check: Run prettier format checkyarn test: Run the unit test suiteyarn test:setup: Start a local development node using Docker (only needs to be run once)yarn lint: Lint with ESLintyarn typecheck: Typecheck withtsc
Please add unit tests when appropriate and ensure that all unit tests are passing before submitting a pull request. Note that some unit tests require a backend node to be running locally. The test:setup command can be run a single time to start the node in the background using Docker.
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 using yarn link or npm link 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 yarn build in the xmtp-js directory and then reload the app.
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