Thank you for your interest in contributing to PublicSuffix for Ruby!
- Fork and clone the repository
- Install dependencies:
bundle install - Create a branch:
git checkout -b feature/your-feature - Make your changes
- Run tests:
rake test - Commit using Conventional Commits format (see below)
- Push and create a pull request
We follow the Conventional Commits specification for commit messages, with a capitalized description. Use the project-specific conventions below.
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
- feat: A new feature
- fix: A bug fix
- chore: Other changes that don't modify src or test files
- docs: Documentation only changes
- style: Code style changes (formatting, etc.)
- refactor: Code change that neither fixes a bug nor adds a feature
- perf: Performance improvement
- test: Adding or updating tests
- build: Changes to build system or external dependencies
- ci: Changes to CI configuration files and scripts
- parser: List parsing and rule handling
- domain: Domain parsing and validation
- list: List management and operations
- rule: Rule definitions and matching
feat(parser): Add support for wildcard exceptions
fix(domain): Handle FQDN trailing dots correctly
docs: Update usage examples in README
refactor(list): Simplify rule lookup logicAdd BREAKING CHANGE: in the footer:
feat(domain): Change parse return type
BREAKING CHANGE: Domain#parse now returns nil for invalid domains instead of raising.
Update code to check for nil returns.
We follow the Common Changelog format for changelog entries.
rake test # Run all tests
rake test TEST=test/domain_test.rb # Run specific test file- Tests use Minitest framework
- Place tests in
test/directory - Use descriptive test names
- Test both happy paths and error cases
- Include tests for edge cases (empty strings, unicode, etc.)
- Update documentation for API changes
- Add tests for new features or bug fixes
- Ensure all tests pass:
rake test - Use Conventional Commits format
- Provide clear PR description with context
- Reference related issues if applicable
- Follow Ruby Style Guide
- Use RuboCop configuration if present
- Add YARD documentation for public methods
- Keep methods focused and small
- Follow idiomatic Ruby patterns
- Use meaningful variable and method names
- Prefer
raiseoverfail - Use blocks and iterators effectively
- Follow the principle of least surprise
- Prefer methods that return values over side effects
- Add YARD comments for public methods
- Include usage examples in documentation
- Update README.md for user-facing changes
- Keep inline comments minimal - prefer self-documenting code
Open an issue for questions, feature discussions, or bug reports.
Thank you for contributing!