Hi, thanks for considering helping!
Packages are developed using Snowdev:
npx snowdev init: Create simple package structure.npx snowdev dev: Start dev server and install ESM dependencies.npx snowdev build: Lint and Format sources, run TypeScript, update README API.npx snowdev release: Bump the version, generate changelog release, create a new commit with git tag.npx snowdev install: Install ESM dependencies.
They're scaffolded from a template structure and Snowdev enforces some conventions:
- code formatting using Prettier 2 defaults
- code linting using ESLint with a basic configuration for compatibility with Babel, Prettier and TypeScript. See snowdev default config
- code comes with type definitions generated using TypeScript and extrapolated from JSDoc definitions in JS-only projects
- commit messages follow the Conventional Commits specification and the Angular preset to generate changelogs and facilitate commit search.
The below comes from sindresorhus who sets the best ground rules for contributing.
Be nice and respect the maintainers' time. ❤️
Please read this whole thing. Most of this applies to any repo on GitHub. 🙏
Code is not the only thing you can contribute. I truly appreciate contributions in the form of:
- Fixing typos.
- Improving docs.
- Triaging issues.
- Reviewing pull requests.
- Sharing your opinion on issues.
- Before opening a new issue, look for existing issues (even closed ones).
- Don't needlessly bump issues.
- If you're reporting a bug, include as much information as possible. Ideally, include a test case that reproduces the bug. For example, a Runkit or repl.it playground. Even better, submit a pull request with a failing test.
- If the changes are large or breaking, open an issue discussing it first.
- Don't open a pull request if you don't plan to see it through. Maintainers waste a lot of time giving feedback on pull requests that eventually go stale.
- Don't do unrelated changes.
- Adhere to the existing code style.
- If relevant, add tests, check for typos, and add docs and types.
- Don't add editor-specific metafiles. Those should be added to your own global gitignore.
- Don't be sloppy. I expect you to do your best.
- Squash your local commits into one commit before submitting the pull request, unless you have important atomic commits.
- Double-check your contribution by going over the diff of your changes before submitting a pull request. It's a good way to catch bugs/typos and find ways to improve the code.
- Do the pull request from a new branch. Never the default branch (
main/master).
- Give the pull request a clear title and description. It's up to you to convince the maintainers why your changes should be merged.
- If the pull request fixes an issue, reference it in the pull request description using the syntax
Fixes #123. - Make sure the “Allow edits from maintainers” checkbox is checked. That way I can make certain minor changes myself, allowing your pull request to be merged sooner.
- Push new commits when doing changes to the pull request. Don't squash as it makes it hard to see what changed since the last review. I will squash when merging.
- It's better to present solutions than asking questions.
- Review the pull request diff after each new commit. It's better that you catch mistakes early than the maintainers pointing it out and having to go back and forth.
- Be patient. Maintainers often have a lot of pull requests to review. Feel free to bump the pull request if you haven't received a reply in a couple of weeks.
- And most importantly, have fun! 👌🎉
Thanks, Damien Seguin.