Thank you for your interest in contributing to DosKit! This document provides guidelines and instructions for contributing to the project.

• Node.js: Version 24.x or higher
• npm: Version 10.x or higher
• Git: For version control

1. Fork the repository on GitHub

2. Clone your fork:

   git clone https://github.com/YOUR_USERNAME/doskit.git
   cd doskit

3. Install dependencies:

   npm install

4. Start the development server:

   npm run dev

5. Open your browser to http://localhost:5173

Use descriptive branch names that follow this pattern:

• feature/description - For new features
• fix/description - For bug fixes
• docs/description - For documentation updates
• refactor/description - For code refactoring
• test/description - For test additions or updates

Example: feature/add-gamepad-support

1. Create a new branch from main:

   git checkout -b feature/your-feature-name

2. Make your changes following the code style guidelines

3. Write or update tests for your changes

4. Run the test suite to ensure all tests pass:

   npm test

5. Run the linter to check code style:

   npm run lint

6. Build the project to ensure it compiles:

   npm run build

Write clear, concise commit messages using conventional commits:

feat: add gamepad support for DOS games

- Implement gamepad API integration
- Add configuration options for button mapping
- Update documentation with gamepad usage

Closes #123

Commit message format:

• feat: - New feature (minor version bump)
• fix: - Bug fix (patch version bump)
• docs: - Documentation changes
• style: - Code style changes (formatting, etc.)
• refactor: - Code refactoring
• test: - Test additions or updates
• chore: - Build process or auxiliary tool changes
• BREAKING CHANGE: - Breaking changes (major version bump)

1. Push your changes to your fork:

   git push origin feature/your-feature-name

2. Create a Pull Request on GitHub from your fork to the main repository

3. Fill out the PR template with:

   • Description of changes
   • Related issue numbers
   • Testing performed
   • Screenshots (if applicable)

4. Wait for review - Maintainers will review your PR and may request changes

5. Address feedback - Make requested changes and push updates to your branch

6. Merge - Once approved, a maintainer will merge your PR

• Use TypeScript for all new code
• Enable strict mode type checking
• Avoid using any type - use unknown, specific types, or proper generics
• Document complex types with JSDoc comments

• Use functional components with hooks
• Follow React best practices and hooks rules
• Use meaningful component and prop names
• Keep components focused and single-purpose

• ESLint: All code must pass ESLint checks
• Indentation: 2 spaces
• Quotes: Single quotes for strings
• Semicolons: Required
• Line length: Maximum 100 characters (soft limit)

Run the linter to auto-fix many style issues:

npm run lint

• Coverage: Maintain minimum 70% code coverage
• Unit tests: Required for all new features and bug fixes
• Component tests: Required for all React components
• Integration tests: Recommended for complex features

# Run tests in watch mode
npm test

# Run tests once
npm run test:run

# Run tests with coverage
npm run test:coverage

# Run tests with UI
npm run test:ui

• Update README.md if you change functionality
• Add JSDoc comments for public APIs and complex functions
• Update type definitions in src/types/ as needed
• Include code examples for new features

If you have questions about contributing:

• Open a GitHub Discussion
• Check existing Issues and Pull Requests
• Contact the maintainer: cameron@rye.dev

By contributing to DosKit, you agree that your contributions will be licensed under the MIT License.

Made with ❤️ by Cameron Rye