UNPKG

ai-cant-even

Version:

A satirical AI-powered utility that's confidently wrong about basic math operations

114 lines (77 loc) 4.37 kB
# Contributing to ai-cant-even --- > ⚠️ **IMPORTANT**: This project enforces strict commit message formatting. All contributors MUST follow our [commit message guidelines](#commit-messages) when submitting changes. Pull requests with non-compliant commit messages will be rejected. --- First off, thank you for considering contributing to `ai-cant-even`! It's people like you that make this satirical AI math library so hilariously wrong. ## Development Process 1. Fork the repository 2. Create your feature branch (`git checkout -b feature/amazing-feature`) 3. Make your changes 4. Run tests to ensure they pass (`npm test`) 5. Run linting to ensure code quality (`npm run lint`) 6. Format your code (`npm run format`) 7. Commit your changes (`git commit -m 'Add some amazing feature'`) 8. Push to the branch (`git push origin feature/amazing-feature`) 9. Open a Pull Request ## Code Style We use ESLint and Prettier to maintain code quality and consistency. Before submitting your code, please run: ```bash npm run lint npm run format ``` ## Testing We use Jest for testing. Please make sure all tests pass before submitting your code: ```bash npm test ``` ### Writing Tests If you're adding new features, please also add appropriate tests. Follow these guidelines for testing: 1. **Test Structure**: Use the describe/it pattern to organize tests 2. **Mock LLM Client**: Use the shared mock implementation for LLM client responses 3. **Test Both Paths**: Test with and without API keys to ensure fallback responses work 4. **Verify Method Calls**: Check that the correct parameters are passed to the LLM client 5. **Test Return Values**: Verify that methods return the expected responses ### Testing Methodology Our testing approach focuses on: - **Unit Testing**: Each method should have its own test cases - **Mocking External Services**: We mock the OpenAI API calls to avoid actual API usage during tests - **State Verification**: For fluent API methods, verify they correctly modify and reset state - **Configuration Testing**: Ensure different confidence levels and logic types work as expected See the existing tests in `src/__tests__/index.test.ts` for examples of our testing patterns. ## Pull Request Process 1. Update the README.md with details of changes if appropriate 2. Update examples if you've changed the API 3. The PR should work for Node.js 16 and above 4. Your PR will be automatically checked by GitHub Actions for: - TypeScript type errors (`type-check`) - Formatting issues (`format:check`) - Linting errors (`lint`) - Test failures (`test`) 5. Fix any issues identified by the automated checks 6. Your PR will be reviewed by maintainers, who may request additional changes ## Commit Messages In order to maintain consistent commit messages, please use an LLM that is familiar with the changes for that commit to assist with the following prompt. Alternatively, human-generated commit messages are acceptable if they follow the same guidelines: ``` Take a look at the `git diff --staged` and generate a commit message for the changes since the last commit The commit message should: 1. Be written in present tense 2. Start with a type (feat, fix, docs, style, refactor, test, chore) 3. Be concise but descriptive 4. Include any breaking changes 5. Maintain a satirical tone consistent with the package's theme ``` For major changes, please open an issue first to discuss what you would like to change. ## Code of Conduct ### Our Pledge In the interest of fostering an open and welcoming environment, we pledge to make participation in our project and our community a harassment-free experience for everyone. ### Our Standards Examples of behavior that contributes to creating a positive environment include: - Using welcoming and inclusive language - Being respectful of differing viewpoints and experiences - Gracefully accepting constructive criticism - Focusing on what is best for the community - Showing empathy towards other community members ### Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. ## License By contributing, you agree that your contributions will be licensed under the project's MIT License.