Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
67 lines (47 loc) · 3.99 KB

CONTRIBUTING.md

File metadata and controls

67 lines (47 loc) · 3.99 KB

Contributing to MCP OpenAPI Schema Explorer

Thank you for considering contributing to this project! We welcome improvements and bug fixes.

Getting Started

  • Devcontainer: The easiest way to get a consistent development environment is to use the provided Dev Container configuration (.devcontainer/). If you have Docker and the VS Code Dev Containers extension installed, simply reopen the project folder in a container.
  • Manual Setup: If you prefer not to use the devcontainer, ensure you have Node.js (v22 or later recommended) and npm installed. Clone the repository and run npm install to install dependencies.

Development Workflow

This project uses just as a command runner for common development tasks. See the justfile for all available commands. Key commands include:

  • just install: Install dependencies (npm install).
  • just format: Format code using Prettier.
  • just lint: Check code for linting errors using ESLint.
  • just build: Compile TypeScript code (npx tsc).
  • just test: Run unit and end-to-end tests using Jest.
  • just test-coverage: Run tests and generate a coverage report.
  • just security: Run security checks (npm audit, license check).
  • just all: Run format, lint, build, test-coverage, and security checks sequentially.

Please ensure just all passes before submitting a pull request.

Code Style

  • Formatting: We use Prettier for automatic code formatting. Please run just format before committing.
  • Linting: We use ESLint for code analysis. Please run just lint to check for issues.

Commit Messages

This project uses semantic-release to automate versioning and releases. Therefore, commit messages must follow the Conventional Commits specification. This allows the release process to automatically determine the version bump (patch, minor, major) and generate changelogs.

Common commit types include:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • chore: Other changes that don't modify src or test files

Example: feat: add support for YAML output format Example: fix: correct handling of remote URL loading errors Example: docs: update README with client configuration examples

Cline & Memory Bank

This project utilizes Cline for AI-assisted development. The memory-bank/ directory contains documentation specifically for Cline's context. Maintaining this memory bank helps ensure Cline can effectively assist with development tasks.

If you make significant changes to the project's architecture, features, or development process, please consider updating the relevant files in memory-bank/. You can learn more about the Cline Memory Bank here.

Submitting Changes

  1. Fork the repository.
  2. Create a new branch for your feature or fix (git checkout -b feat/my-new-feature or git checkout -b fix/my-bug-fix).
  3. Make your changes.
  4. Ensure all checks pass (just all).
  5. Commit your changes using the Conventional Commits format.
  6. Push your branch to your fork (git push origin feat/my-new-feature).
  7. Open a pull request against the main branch of the original repository.

Thank you for your contribution!