Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
171 lines (125 loc) · 4.69 KB

CONTRIBUTING.md

File metadata and controls

171 lines (125 loc) · 4.69 KB

Contributing to wirekit

First off, thanks for taking the time to contribute! 🎉

The following is a set of guidelines for contributing to wirekit. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table of Contents

Code of Conduct

This project and everyone participating in it is governed by our commitment to providing a welcoming and inclusive environment. Please be respectful and constructive in all interactions.

How Can I Contribute?

Reporting Bugs

Before creating bug reports, please check existing issues to avoid duplicates. When you create a bug report, include as many details as possible:

  • Use a clear and descriptive title
  • Describe the exact steps to reproduce the problem
  • Provide specific examples (code snippets, error messages)
  • Describe the expected behavior
  • Include your Go version (go version)
  • Include your OS and version

Suggesting Enhancements

Enhancement suggestions are welcome! Please provide:

  • Use a clear and descriptive title
  • Provide a detailed description of the suggested enhancement
  • Explain why this enhancement would be useful
  • Provide code examples if applicable

Pull Requests

  1. Fork the repository and create your branch from main
  2. Make your changes following our style guidelines
  3. Add tests for any new functionality
  4. Ensure all tests pass (go test ./...)
  5. Run linters (golangci-lint run)
  6. Update documentation if needed
  7. Submit your pull request

Development Setup

# Clone your fork
git clone https://github.com/YOUR_USERNAME/wirekit.git
cd wirekit

# Add upstream remote
git remote add upstream https://github.com/yigithankarabulut/wirekit.git

# Install dependencies
go mod download

# Run tests
go test -v ./...

# Run linter
golangci-lint run

Style Guidelines

Go Code Style

  • Follow the official Go Code Review Comments
  • Run go fmt ./... before committing
  • Run go vet ./... to check for issues
  • Use meaningful variable and function names
  • Add comments for exported functions and types (GoDoc)
  • Keep functions focused and small

Package Guidelines

  • Each package should have a clear, single responsibility
  • Use interfaces for flexibility and testability
  • Follow the builder pattern for configuration (as established in the project)
  • Provide sensible defaults (Convention over Configuration)

Testing

  • Write unit tests for all new functionality
  • Use table-driven tests where appropriate
  • Aim for meaningful test coverage
  • Test both success and error cases

Example:

func TestSomething(t *testing.T) {
    tests := []struct {
        name    string
        input   string
        want    string
        wantErr bool
    }{
        {"valid input", "hello", "HELLO", false},
        {"empty input", "", "", true},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := Something(tt.input)
            if (err != nil) != tt.wantErr {
                t.Errorf("Something() error = %v, wantErr %v", err, tt.wantErr)
                return
            }
            if got != tt.want {
                t.Errorf("Something() = %v, want %v", got, tt.want)
            }
        })
    }
}

Commit Messages

We use Conventional Commits specification:

Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests or correcting existing tests
  • chore: Changes to the build process or auxiliary tools

Examples

feat(redis): add cluster support

fix(postgres): handle connection timeout properly

docs: update README with new examples

test(jwt): add validation edge cases

chore: update dependencies

Scope (optional)

Use package names as scope: postgres, redis, kafka, log, jwt, etc.

Questions?

Feel free to open an issue with the "question" label if you have any questions about contributing.

Thank you for contributing! 🙏