Thank you for your interest in contributing to MCP DevTools! This document provides guidelines and instructions for contributing to this project.
- Code of Conduct
- Getting Started
- Development Workflow
- Pull Request Process
- Coding Standards
- Commit Guidelines
- Testing
- Documentation
- Release Process
By participating in this project, you are expected to uphold our Code of Conduct:
- Be respectful and inclusive
- Use welcoming and inclusive language
- Be collaborative and constructive
- Focus on what is best for the community
- Show empathy towards other community members
- Fork the repository on GitHub
- Clone your fork locally:
git clone https://github.com/YOUR-USERNAME/mcp-devtools.git cd mcp-devtools
- Install dependencies:
pnpm install
- Build the packages:
pnpm build
-
Create a new branch for your feature or bugfix:
git checkout -b feature/your-feature-name
-
Make your changes, following the coding standards
-
For development with auto-rebuild:
pnpm dev
-
Test your changes:
pnpm test
-
Lint your code:
pnpm lint
-
Commit your changes following the commit guidelines
- Update the README.md and documentation with details of changes, if applicable
- Ensure all tests pass and code linting is clean
- Submit a pull request to the
main
branch of the original repository - The maintainers will review your PR and provide feedback
- Once approved, your PR will be merged
- Follow the existing code style
- Use TypeScript for all new code
- Ensure code is properly typed
- Follow the principle of clean code
- Use meaningful variable and function names
- Write comments for non-obvious code
- Keep functions small and focused on a single responsibility
- Use interfaces for object types
- Use proper access modifiers for class members
- Avoid using
any
type where possible - Use arrow functions for callbacks
- Use async/await instead of Promise chains when appropriate
This project uses Conventional Commits to automate versioning and changelog generation. Please format your commit messages following this pattern:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Types:
feat
: A new featurefix
: A bug fixdocs
: Documentation changesstyle
: Changes that don't affect the code's meaning (formatting, etc.)refactor
: Code changes that neither fix bugs nor add featuresperf
: Performance improvementstest
: Adding or fixing testschore
: Changes to the build process or auxiliary tools
Examples:
feat(jira): add comment creation endpoint
fix(http-client): resolve timeout issue
docs: update README with new setup instructions
Breaking changes should be indicated by adding an exclamation mark after the type/scope and describing the breaking change in the body of the commit message:
feat!: redesign http-client API
BREAKING CHANGE: The http-client API has been completely redesigned to improve usability.
- Write tests for all new features and bug fixes
- Ensure all existing tests pass before submitting a PR
- Follow the existing testing patterns in the codebase
- Aim for high test coverage, especially for critical functionality
To run tests:
# Run all tests
pnpm test
# Run specific tests
pnpm test -- --grep="pattern"
- Update documentation for any changed functionality
- Document all public APIs
- Ensure README.md is kept up-to-date
- Add JSDoc comments to functions and classes
- Include code examples where appropriate
This repository is set up with automated release management using release-please and GitHub Actions for publishing packages to npmjs.org.
All published packages are currently in beta status (0.x.x versions) and use the beta
npm tag. During this phase:
- Breaking changes may occur in minor version updates
- Install the packages using:
npm install @mcp-devtools/package-name@beta
- When the project reaches stability, we will release version 1.0.0
If you need help with contributing, please:
- Check the existing issues on GitHub
- Open a new issue if your question isn't already addressed
- Reach out to the maintainers through the project's communication channels
Thank you for contributing to MCP DevTools!