Interested in contributing? Great! Here are some suggestions to make it a good experience:
Start by opening an issue, whether to identify a problem or outline a change. That issue should be used to discuss the situation and agree on a plan of action before writing code or sending a pull request. Maybe the problem isn't really a problem, or maybe there are more things to consider. If so, it's best to realize that before spending time and effort writing code that gets rejected.
Match the coding style of the files you edit. Although everyone has their own preferences and opinions, a pull request is not the right forum to debate them.
Do not add new dependencies to package.json.
Package versions for dependencies and devDependencies should be specified
exactly (also known as "pinning"). Doing otherwise causes inconsistent behavior
and broken functionality. (See Why I pin dependency versions in Node.js
packages for a longer explanation.)
Add tests for all new/changed functionality. Test both positive and negative scenarios. Try to break the new code now, or it will get broken later. This project maintains 100% code coverage.
Run tests before sending a pull request via npm test. Tests need to pass on
all platforms. Test cases are implemented in test/*.mjs. To update test
snapshots (for example, after modifying a test file), use npm run update-snapshots and include the updated snapshot files with the pull request.
Run a full continuous integration pass before opening a pull request via npm run ci. As part of the continuous integration run, generated files may get
updated and fail the run - commit those changes and rerun.
Pull requests should contain a single commit with a commit message that is a brief sentence with punctuation. Include the text "(fixes #??)" at the end of the commit message so the pull request will be associated with the relevant issue. Squash multiple commits before creating the pull request or when making updates. (See Git Tools - Rewriting History for details.)
Create all pull requests for the next branch which contains the latest changes
ready for release. Once accepted, the tag fixed in next will be added to the
issue. When that commit is merged to the main branch during the release
process, the issue will be closed automatically.
Refrain from using slang or meaningless placeholder text in code, documentation, or tests. Sample content can be "text", "code", "heading", etc.. URLs should use example.com. Profanity is not allowed.
In order to maintain the permissive MIT license this project has, all contributions must be your own and released under the MIT license. Code you add should be an original work and should not be copied from elsewhere. Reusing code from a different project, Stack Overflow, etc. is not allowed. The use of tools such as Copilot, ChatGPT, Claude, etc. that produce output from a large language model (LLM) is not allowed because LLMs reuse code from other projects.
Thank you!