Thank you for your interest in contributing to go-generics! This document provides guidelines for contributing to this project.
- Go 1.24.0 or later
- Docker or Podman (for Redis integration tests)
- Make
- Check existing issues and PRs to avoid duplicating work
- Create an issue for major changes to discuss the approach
- Follow existing code patterns and conventions
- Write generic, reusable code that follows Go best practices
- Include comprehensive documentation with examples
- Ensure your code has no instances of exponential time complexity
- Avoid n+1 network request patterns
- Use meaningful variable and function names
The project is organized into focused packages:
functions/- Generic utility functions with concurrency supportdatastructures/- Generic data structures (Set, Stack, etc.)cache/- Generic caching implementationsratelimit/- Rate limiting functionalityconcurrency/- Concurrency utilities and distributed lockingencryption/- Generic encryption/decryption utilitiesserialize/- Serialization helpers
# Run all unit tests
make test
# Run tests with coverage
make test-coverage
# Run fuzz tests (30 seconds)
make test-fuzz
# Start Redis and run Redis integration tests
make test-redis
- All new code must include comprehensive tests
- Tests should use the
//go:build testbuild tag - Use the
internal/testpackage helpers for assertions - Include both unit tests and integration tests where applicable
- Test edge cases and error conditions
- Aim for high test coverage
//go:build test
// +build test
package yourpackage
import (
"testing"
"github.com/zendesk/go-generics/internal/test"
)
func TestYourFunction(t *testing.T) {
// Use test.CheckOk, test.CheckEqual, etc.
}- Use
gofmtfor code formatting:make fmt - Follow standard Go naming conventions
- Use meaningful comments for exported functions and types
- Update README.md for new features
- Ensure all tests pass:
make test - Run
make fmtto format your code - Update documentation as needed
- Add/update tests for your changes
Your PR should include:
- Clear description of changes and purpose
- Code follows existing design conventions
- No exponential time complexity
- No n+1 network request patterns
- Updated relevant documentation
- Comprehensive test coverage
- All tests pass
Please include:
- Purpose: What problem does this solve or what feature does it add?
- Changes: What specific changes were made?
- Compromises: Any trade-offs or decisions made during implementation
- Risks: Any potential risks introduced by the changes
By contributing to this project, you agree that your contributions will be licensed under the Apache License 2.0.