First off, thank you for considering contributing to DWN-Server. It's people like you that make DWN-Server such a great tool. Given that we're still in early stages of development, this contribution guide will certainly change as we near a release. Until then, things will be a bit ragtag but there's still plenty of opportunities for contribution.
We take our open-source community seriously. Please adhere to our Code of Conduct.
- Feel free to open issues for any reason as long as you make it clear what the issue pertains to.
- Before opening new issues, please search to check if there is an existing issue.
- Existing issues with labels
bug
,documentation
,good first issue
,help wanted
are excellent candidates for contribution, and we'd be thrilled to get all the help we can get. You can take a look at all the Issues that match the these labels here - If planning to work on non-trivial issue involving major/significant changes please check with us first on the implementation approach
- Leave explanation of the approach and tag both @adam4leos and @finn-tbd in the issue
- Good idea to also post link to the issue in our dwn discord channel to initiate discussion with more people
- Check to see if anyone is already working on the issue by looking to see if the issue has a
WIP
tag. - Fork the repository
- Create a branch named the issue number you're taking on (usually branch from
main
) - Push that branch and create a draft PR
- Paste a link to the draft PR in the issue you're tackling
- We'll add the
WIP
tag for you - Work away. Feel free to ask any/all questions that crop up along the way
- When ready, switch the draft PR to "Ready for review".
- If you've added code that should be tested, add tests.
- Update the README.md with details of changes to the interface, if applicable.
- Running the
npm run test
command from the root of the project will run all tests.- This is run via CI whenever a pull request is opened, or a commit is pushed to a branch that has an open PR.
- Make sure to cover added code with tests, if it should be tested
- Codecov is used to track the coverage of our tests and will automatically comment on every pull request showing the impact to overall coverage.
- If your pull request introduces new features or changes existing logic, please ensure you include comprehensive tests that cover edge-cases and failure scenarios. This ensures that your contributions are of the highest quality and safeguards our codebase against potential bugs or breaking changes.
- Thorough tests are also a great way to better understand your proposed changes.
- If you encounter any difficulties while writing tests, don't hesitate to reach out for help or guidance in our Web5 Discord channel.
- Our preferred code style has been codified into
eslint
.- Feel free to take a look onto eslint config.
- Running
npm run lint:fix
will auto-format as much they can. Everything they weren't able to will be printed out as errors or warnings. - We have a pre-commit hook which would run both commands with attempt to autofix problems
- It runs by husky and executes lint-staged command
- Make sure that no errors/warnings are introduced in your PR
- A
TODO
in comment must always link to a GitHub issue.
Script | Description |
---|---|
npm run build:esm |
compiles typescript into ESM JS |
npm run build:cjs |
compiles typescript into CommonJS |
npm run build |
compiles typescript into ESM JS & CommonJS |
npm run clean |
deletes compiled JS |
npm run lint |
runs linter |
npm run lint:fix |
runs linter and fixes auto-fixable problems |
npm run test |
runs tests |
npm run server |
starts server |
npm run prepare |
prepares husky for pre-commit hooks (auto-runs with npm install ) |