Thank you for your interest in contributing to NutJS Windows Control! This document provides guidelines and instructions for contributing to the project.
- Code of Conduct
- Getting Started
- Development Workflow
- Code Style and Standards
- Testing
- Documentation
- Project Structure
- Issue Tracking
- Future Roadmap
Please be respectful and considerate of others when contributing to this project. We aim to foster an inclusive and welcoming community.
- Node.js (latest LTS version recommended)
- npm
- git
- cmake-js (for building libnut-core)
- C++ compiler (for building native modules)
-
Fork the repository
-
Clone your fork:
git clone https://github.com/YOUR-USERNAME/MCPControl.git cd MCPControl -
Build the project (this will handle libnut-core and all dependencies):
# Install dependencies npm install # Build everything including libnut-core npm run build:all
For manual building, you can follow these steps instead:
# Install cmake-js globally (required for building) npm install -g cmake-js # Clone libnut repository directly in the project directory git clone https://github.com/nut-tree/libnut.git libnut-core cd libnut-core # Install dependencies and build npm install cmake-js rebuild # Return to the main project cd .. # Build MCPControl npm run build
masterbranch contains the latest stable code- Create feature branches from
masterusing the naming convention:feature/feature-namefor new featuresbugfix/issue-descriptionfor bug fixesdocs/descriptionfor documentation changesrefactor/descriptionfor code refactoring
- Write clear, descriptive commit messages
- Reference issue numbers in commit messages when applicable
- Keep commits focused on a single logical change
- Create your feature branch:
git checkout -b feature/amazing-feature - Commit your changes:
git commit -m 'Add some amazing feature' - Push to the branch:
git push origin feature/amazing-feature - Open a Pull Request
- Ensure all tests pass and code meets the project standards
- Request a review from a maintainer
- Use ES module syntax with named imports
- Define TypeScript interfaces for inputs/outputs in the
types/directory - Use try/catch with standardized response objects for error handling
- Follow naming conventions:
- camelCase for variables/functions
- PascalCase for interfaces
- Keep functions small and focused on single responsibility
- Add JSDoc comments for public APIs
- Use 2-space indentation and semicolons
- For errors, return
{ success: false, message: string } - For success, return
{ success: true, data?: any }
- Place tests in the same directory as implementation with
.test.tssuffix - Run tests with
npm run test - Generate coverage report with
npm run test:coverage - Run a single test with
npm run test -- tools/keyboard.test.tsornpm run test -- -t "specific test name" - Run tests in watch mode with
npm run test:watch
All new features should include appropriate test coverage. The project uses Vitest for testing.
- Document public APIs with JSDoc comments
- Update README.md when adding new features or changing functionality
- Keep code comments clear and focused on explaining "why" rather than "what"
/src/handlers- Request handlers and tool management/tools- Core functionality implementations/types- TypeScript type definitionsindex.ts- Main application entry point
Check the GitHub issues for existing issues you might want to contribute to. Current focus areas include:
- Creating an npm package for easy installation
- Adding remote computer control support
- Building a dedicated test application
When creating a new issue:
- Use descriptive titles
- Include steps to reproduce for bugs
- For feature requests, explain the use case and potential implementation approach
See the TASKS.md file for the current roadmap and planned features, which include:
- Security implementation improvements
- Comprehensive testing
- Error handling enhancements
- Performance optimization
- Automation framework
- Enhanced window management
- Advanced integration features
Thank you for contributing to NutJS Windows Control!