Thank you for your interest in contributing to DotGitHub! This guide will help you get started with contributing to the project.
- Code of Conduct
- Getting Started
- Development Setup
- Project Structure
- Making Changes
- Testing
- Submitting Changes
- Release Process
This project adheres to a code of conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to conduct@dotgithub.dev.
Before you begin, ensure you have:
- Node.js 18.0.0 or higher
- Bun 1.2.19 or higher (package manager)
- Git for version control
- GitHub account for contributing
- Fork the repository on GitHub
- Clone your fork locally:
git clone https://github.com/yourusername/dotgithub.git
cd dotgithub- Add the upstream repository:
git remote add upstream https://github.com/azwebmaster/dotgithub.gitInstall all dependencies using Bun:
bun installBuild all packages:
bun run buildRun the test suite:
bun run testRun tests in watch mode:
bun run test:watchRun tests with coverage:
bun run test:coverage- Create a branch for your changes:
git checkout -b feature/your-feature-name-
Make your changes following the coding standards
-
Test your changes:
bun run test
bun run build-
Commit your changes with a descriptive message
-
Push to your fork:
git push origin feature/your-feature-name- Create a pull request on GitHub
dotgithub/
├── packages/ # Monorepo packages
│ ├── cli/ # CLI package
│ │ ├── src/
│ │ │ ├── commands/ # CLI commands
│ │ │ └── index.ts # CLI entry point
│ │ └── package.json
│ └── core/ # Core package
│ ├── src/
│ │ ├── constructs/ # Workflow constructs
│ │ ├── plugins/ # Construct system
│ │ ├── types/ # Type definitions
│ │ └── index.ts # Core entry point
│ └── package.json
├── examples/ # Example projects
│ └── example/ # Basic example
├── docs/ # Documentation
├── dist/ # Built files
├── package.json # Root package.json
└── README.md
- @dotgithub/cli - Command-line interface
- @dotgithub/core - Core functionality and types
- Use TypeScript for all new code
- Follow the existing code style
- Use meaningful variable and function names
- Add JSDoc comments for public APIs
- Use strict type checking
- Use 2 spaces for indentation
- Use single quotes for strings
- Use trailing commas in objects and arrays
- Use semicolons
- Maximum line length: 100 characters
- Use kebab-case for file names
- Use PascalCase for class names
- Use camelCase for function and variable names
- Create a new command file in
packages/cli/src/commands/ - Implement the command following the existing pattern
- Export the command from the main CLI file
- Add tests for the command
- Update documentation
Example command structure:
import { Command } from 'commander';
import { DotGithubContext, logger } from '@dotgithub/core';
export function createMyCommand(
createContext: (options?: any) => DotGithubContext
): Command {
return new Command('my-command')
.description('Description of what the command does')
.option('--option <value>', 'Description of the option')
.action(async (options) => {
try {
const context = createContext(options);
// Command logic here
logger.success('Command completed successfully');
} catch (err) {
logger.failure('Command failed', {
error: err instanceof Error ? err.message : String(err),
});
process.exit(1);
}
});
}- Add the feature to the appropriate package (
@dotgithub/core) - Export the feature from the package's index file
- Add TypeScript types and interfaces
- Write comprehensive tests
- Update documentation
When adding construct-related features:
- Follow the existing construct interface
- Add proper validation and error handling
- Include configuration schema validation
- Write tests for different configurations
- Update construct documentation
Tests are organized by package:
packages/cli/src/commands/*.test.ts- CLI command testspackages/core/src/**/*.test.ts- Core functionality tests
Use Vitest for testing. Follow these patterns:
import { describe, it, expect, beforeEach, afterEach } from 'vitest';
import { MyFunction } from './my-function';
describe('MyFunction', () => {
beforeEach(() => {
// Setup
});
afterEach(() => {
// Cleanup
});
it('should do something', () => {
const result = MyFunction('input');
expect(result).toBe('expected output');
});
it('should handle errors', () => {
expect(() => MyFunction('invalid')).toThrow('Error message');
});
});Maintain high test coverage:
- Aim for 90%+ coverage
- Test both success and error cases
- Test edge cases and boundary conditions
- Mock external dependencies
# Run all tests
bun run test
# Run tests for specific package
bun run --filter './packages/cli' test
# Run tests in watch mode
bun run test:watch
# Run tests with coverage
bun run test:coverage
# Run tests for changed files
bun run test:changed- Create a descriptive title that explains what the PR does
- Write a detailed description including:
- What changes were made
- Why the changes were necessary
- How to test the changes
- Any breaking changes
- Link related issues using keywords like "Fixes #123" or "Closes #456"
- Ensure all tests pass and coverage is maintained
- Update documentation if needed
## Description
Brief description of the changes
## Type of Change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
## Testing
- [ ] Tests pass locally
- [ ] New tests added for new functionality
- [ ] Manual testing completed
## Checklist
- [ ] Code follows the project's coding standards
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No breaking changes (or breaking changes documented)- Automated checks must pass (tests, linting, build)
- Code review by maintainers
- Approval from at least one maintainer
- Merge by maintainers
We use Changesets for version management:
- Create a changeset for your changes:
bun run changeset- Follow the prompts to describe your changes
- Commit the changeset file
- Maintainers will handle versioning and publishing
- Patch - Bug fixes, documentation updates
- Minor - New features, new commands
- Major - Breaking changes
Releases are automatically published to GitHub Packages when changesets are merged to main.
- Use the example project for testing:
cd examples/example
bun install
bun run build- Link packages locally for testing:
bun link
cd examples/example
bun link @dotgithub/cli @dotgithub/core- Use the CLI locally:
bun run cli --help- Use debug logging:
bun run cli --debug your-command- Add console.log statements for debugging
- Use the browser dev tools for debugging tests
- Profile your code for performance issues
- Use efficient algorithms and data structures
- Minimize external API calls
- Cache expensive operations
- GitHub Discussions - Ask questions and discuss ideas
- GitHub Issues - Report bugs and request features
- Discord - Real-time chat and support
- @azwebmaster - Project maintainer
By contributing to DotGitHub, you agree that your contributions will be licensed under the MIT License.
Thank you for contributing to DotGitHub! Your contributions help make the project better for everyone.