Thank you for your interest in contributing to the ADL CLI! This guide will help you get started with contributing to the project.
- Code of Conduct
- Getting Started
- Development Setup
- Contributing Guidelines
- Submitting Changes
- Adding Language Support
- Testing
- Documentation
- Community
This project adheres to a code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the project maintainers.
- Go 1.26 or later
- Git
- Task (recommended for development tasks)
- Docker (for testing container builds)
-
Fork the repository
# Fork the repo on GitHub, then clone your fork git clone https://github.com/YOUR_USERNAME/adl-cli.git cd adl-cli
-
Add upstream remote
git remote add upstream https://github.com/inference-gateway/adl-cli.git
-
Install dependencies
go mod download
-
Verify setup
# Run tests task test # Run linting task lint # Build the CLI task build
We welcome several types of contributions:
- 🐛 Bug fixes - Fix issues in existing functionality
- ✨ New features - Add new capabilities to the CLI
- 🌍 Language support - Add support for new programming languages
- 📝 Documentation - Improve docs, examples, or help content
- 🧪 Tests - Add or improve test coverage
- 🔧 Tooling - Improve development tools and processes
- Check existing issues - Look for existing issues or discussions about your idea
- Create an issue - For new features or significant changes, create an issue first to discuss the approach
- Small changes - For small bug fixes or documentation improvements, you can go directly to creating a PR
- Follow standard Go conventions (
gofmt,golint) - Use meaningful variable and function names
- Add comments for exported functions and complex logic
- Keep functions focused and reasonably sized
- Use early returns to reduce nesting
- Place new language templates in
internal/templates/ - Add new commands in
cmd/ - Use the existing error handling patterns
- Follow the current project structure
Use clear, descriptive commit messages:
feat: add TypeScript template support
- Add TypeScript template with Express.js framework
- Include enterprise features (auth, metrics, logging)
- Add corresponding tests and documentation
Fixes #123
Format: type: description
Types:
feat:- New featurefix:- Bug fixdocs:- Documentation changestest:- Adding or updating testsrefactor:- Code refactoringchore:- Maintenance tasks
-
Create a feature branch
git checkout -b feature/your-feature-name
-
Make your changes
- Write code following our standards
- Add tests for new functionality
- Update documentation as needed
-
Test your changes
# Run all tests task test # Run linting task lint # Test with examples task examples:test
-
Commit and push
git add . git commit -m "feat: your descriptive commit message" git push origin feature/your-feature-name
-
Create a Pull Request
- Use a clear title and description
- Reference any related issues
- Include screenshots for UI changes
- Add reviewers if you know who should review
- Code follows project conventions
- Tests pass (
task test) - Linting passes (
task lint) - Documentation updated (if applicable)
- Examples work (if adding new functionality)
- Commit messages are clear and descriptive
Adding support for a new programming language is a significant contribution. Here's how to approach it:
- Create an issue to discuss the language addition
- Define the scope and features for the language template
- Identify the web framework and dependencies to use
Update internal/schema/types.go to add language configuration:
type LanguageSpec struct {
Go *GoConfig `yaml:"go,omitempty"`
TypeScript *TypeScriptConfig `yaml:"typescript,omitempty"`
Rust *RustConfig `yaml:"rust,omitempty"` // New language
// ... other languages
}
type RustConfig struct {
Edition string `yaml:"edition"` // e.g., "2021"
Framework string `yaml:"framework"` // e.g., "axum"
AsyncRuntime string `yaml:"runtime"` // e.g., "tokio"
}Create templates in internal/templates/:
// internal/templates/rust.go
package templates
func getRustTemplate() map[string]string {
return map[string]string{
"Cargo.toml": rustCargoTemplate,
"src/main.rs": rustMainTemplate,
"src/handlers.rs": rustHandlersTemplate,
// ... other files
}
}
const rustMainTemplate = `// Rust main template
use axum::{routing::post, Router};
// ... template content
`Update internal/templates/engine.go to handle the new language:
func (e *Engine) GetFiles() map[string]string {
switch e.templateName {
case "rust":
return getRustTemplate()
// ... existing cases
}
}Update internal/generator/generator.go for language detection and validation.
- Add tests for the new language
- Create example ADL files in
examples/ - Test the template thoroughly
- Verify generated code compiles and runs
- Update README.md roadmap
- Add language-specific documentation
- Include example ADL files
- Document any language-specific features
# Run all tests
task test
# Run tests with coverage
task test:coverage
# Run specific tests
go test ./internal/generator -v
# Test examples
task examples:test- Use table-driven tests when appropriate
- Test both success and error cases
- Mock external dependencies
- Include integration tests for end-to-end flows
Example test structure:
func TestGenerator_GenerateRust(t *testing.T) {
tests := []struct {
name string
adlFile string
wantFiles []string
wantErr bool
}{
{
name: "rust template",
adlFile: "testdata/rust-agent.yaml",
wantFiles: []string{"Cargo.toml", "src/main.rs"},
wantErr: false,
},
// ... more test cases
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
// Test implementation
})
}
}- Code Comments - Document exported functions and complex logic
- README.md - Keep the main README updated
- Examples - Add practical examples for new features
- ADL Documentation - Document new ADL schema fields
- Use clear, concise language
- Include code examples
- Keep examples up to date
- Test documentation examples
- Discussions: Use GitHub Discussions for questions
- Issues: Use GitHub Issues for bugs and feature requests
- Maintainer Review - A project maintainer will review your PR
- Community Feedback - Other contributors may provide feedback
- CI Checks - Automated tests must pass
- Approval - At least one maintainer approval required for merge
Contributors will be recognized in:
- GitHub contributors list
- Release notes for significant contributions
- Project documentation
The ADL CLI follows semantic versioning:
- Patch (1.0.1) - Bug fixes and small improvements
- Minor (1.1.0) - New features, backward compatible
- Major (2.0.0) - Breaking changes
Releases are managed by maintainers, but contributors can suggest features for upcoming releases.
If you have questions about contributing:
- Check this guide and existing documentation
- Search existing issues and discussions
- Create a new discussion or issue
- Reach out to maintainers
Thank you for contributing to ADL CLI! 🚀
This guide is inspired by best practices from the Go community and other successful open-source projects.