First off, thank you for considering contributing to TypeSentry! It's people like you that make TypeSentry such a great tool.
By participating in this project, you are expected to uphold our Code of Conduct. Please be respectful and considerate of others. Unacceptable behavior will not be tolerated.
This section guides you through submitting a bug report for TypeSentry. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Provide specific examples to demonstrate the steps.
This section guides you through submitting an enhancement suggestion for TypeSentry, including completely new features and minor improvements to existing functionality.
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a step-by-step description of the suggested enhancement in as many details as possible.
- Provide specific examples to demonstrate the steps.
Unsure where to begin contributing to TypeSentry? You can start by looking through the existing issues in our GitHub repository. Look for issues that are good for first-time contributors or areas where help is needed.
When submitting a pull request:
- Provide a clear and descriptive title
- Include a detailed description of the changes
- Reference any related issues in the description
- Follow the TypeScript styleguide
- Include tests that cover your changes
- Update documentation as necessary
- Ensure all tests pass before submitting
- 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
- Use 2 spaces for indentation
- Prefer
const
overlet
. Only uselet
if rebinding is necessary - Use PascalCase for type names
- Do not use
I
as a prefix for interface names - Use PascalCase for enum values
- Use camelCase for function names
- Use camelCase for property names and local variables
- Do not use
_
as a prefix for private properties - Use whole words in names when possible
- Use Markdown for documentation.
- Reference methods and classes in markdown with the custom
{}
notation:- Reference classes with
{ClassName}
- Reference instance methods with
{ClassName.methodName}
- Reference class methods with
{ClassName.methodName}
- Reference classes with
Thank you for contributing to TypeSentry!