Skip to content

Latest commit

 

History

History
119 lines (92 loc) · 4.45 KB

CONTRIBUTING.md

File metadata and controls

119 lines (92 loc) · 4.45 KB

Contributing to rust-errors

First off, thank you for considering contributing to rust-errors! It's people like you that make rust-errors such a great tool.

Code of Conduct

This project and everyone participating in it is governed by our Code of Conduct. By participating, you are expected to uphold this code.

How Can I Contribute?

Reporting Bugs

Before creating bug reports, please check the issue list as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible:

  • Use a clear and descriptive title
  • Describe the exact steps which reproduce the problem
  • Provide specific examples to demonstrate the steps
  • Describe the behavior you observed after following the steps
  • Explain which behavior you expected to see instead and why
  • Include code samples and error messages

Suggesting Enhancements

Enhancement suggestions are tracked as GitHub issues. When creating an enhancement suggestion, please include:

  • Use a clear and descriptive title
  • Provide a step-by-step description of the suggested enhancement
  • Provide specific examples to demonstrate the steps
  • Describe the current behavior and explain which behavior you expected to see instead
  • Explain why this enhancement would be useful
  • List some other libraries or applications where this enhancement exists

Pull Requests

  • Fill in the required template
  • Do not include issue numbers in the PR title
  • Include screenshots and animated GIFs in your pull request whenever possible
  • Follow the TypeScript styleguide
  • Include thoughtfully-worded, well-structured tests
  • Document new code based on the Documentation Styleguide
  • End all files with a newline

Development Process

  1. Fork the repo and create your branch from main
  2. Run bun install to install dependencies
  3. Make your changes
  4. Add tests for any new functionality
  5. Run bun test to ensure all tests pass
  6. Run bun run lint to ensure your code follows our style guide
  7. Run bun run build to ensure your changes compile correctly
  8. Create a pull request

Styleguides

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • Consider starting the commit message with an applicable emoji:
    • 🎨 :art: when improving the format/structure of the code
    • 🐎 :racehorse: when improving performance
    • 🚱 :non-potable_water: when plugging memory leaks
    • 📝 :memo: when writing docs
    • 🐛 :bug: when fixing a bug
    • 🔥 :fire: when removing code or files
    • 💚 :green_heart: when fixing the CI build
    • ✅ :white_check_mark: when adding tests
    • 🔒 :lock: when dealing with security
    • ⬆️ :arrow_up: when upgrading dependencies
    • ⬇️ :arrow_down: when downgrading dependencies

TypeScript Styleguide

  • Use strict TypeScript settings
  • Avoid using any type
  • Use private class fields with # prefix
  • Use readonly where possible
  • Use type inference where it makes code clearer
  • Document public APIs with JSDoc comments
  • Use consistent naming conventions:
    • PascalCase for types and classes
    • camelCase for functions and variables
    • UPPER_CASE for constants
  • Prefer type aliases over interfaces for public APIs
  • Use union types instead of enums
  • Use type guards for runtime type checking

Documentation Styleguide

  • Use TypeDoc for API documentation
  • Write documentation in Markdown
  • Reference types and code using backticks
  • Include examples in documentation
  • Document both success and error cases
  • Explain complex algorithms and design decisions
  • Keep documentation up to date with code changes

Additional Notes

Issue and Pull Request Labels

This section lists the labels we use to help us track and manage issues and pull requests.

  • bug - Issues that are bugs
  • documentation - Issues about documentation
  • duplicate - Issues that are duplicates of other issues
  • enhancement - Issues that are feature requests
  • good first issue - Good for newcomers
  • help wanted - Extra attention is needed
  • invalid - Issues that aren't valid
  • question - Further information is requested
  • wontfix - Issues that won't be worked on

Questions?

If you have any questions, please feel free to contact the project maintainers.