Contributing to Speechify
July 13, 2025 ยท View on GitHub
Thank you for your interest in contributing to Speechify! This document provides guidelines and information for contributors.
๐ฏ Project Overview
Speechify is a VS Code extension that converts text to speech using Azure Speech Services. Our goal is to provide an accessible, high-quality, and user-friendly text-to-speech solution for developers and content creators.
๐ ๏ธ Development Setup
Prerequisites
- Node.js: Version 16.x or higher
- VS Code: Latest stable version
- Git: For version control
- Azure Account: For testing speech services (optional but recommended)
Getting Started
-
Fork and Clone
git clone https://github.com/YOUR_USERNAME/speechify.git cd speechify -
Install Dependencies
npm install -
Set Up Development Environment
# Compile TypeScript npm run compile # Start watch mode for development npm run watch -
Create Test Configuration (Optional)
# Create test-config.json for Azure API testing cp test-config.example.json test-config.json # Edit with your Azure credentials (never commit this file!) -
Run Tests
npm run test:integration npm run lint
๐ Project Structure
speechify/
โโโ src/
โ โโโ extension.ts # Main extension entry point
โ โโโ types/ # TypeScript type definitions
โ โโโ utils/ # Utility functions
โ โโโ services/ # Core business logic
โ โโโ i18n/ # Internationalization
โ โโโ test/ # Test suites
โโโ .github/ # GitHub templates and workflows
โโโ package.json # Extension manifest
โโโ README.md # Documentation
๐จ Coding Standards
TypeScript Guidelines
- Strict Mode: All code must compile with strict TypeScript settings
- Type Safety: Use explicit types, avoid
anywhen possible - Naming: Use camelCase for variables/functions, PascalCase for classes/types
- Comments: Document complex logic and public APIs
Code Style
// โ
Good
interface VoiceSettings {
name: string;
style?: string;
role?: string;
}
async function convertTextToSpeech(text: string, settings: VoiceSettings): Promise<void> {
// Implementation with proper error handling
}
// โ Avoid
function doStuff(data: any): any {
// No error handling, unclear naming
}
Internationalization
- Always use i18n: Never hardcode user-facing strings
- Message Keys: Use hierarchical naming (e.g.,
commands.convert.success) - Placeholders: Use typed interpolation for dynamic content
// โ
Correct
vscode.window.showInformationMessage(I18n.t('commands.convert.success', fileName));
// โ Wrong
vscode.window.showInformationMessage('Conversion completed');
๐งช Testing
Test Categories
- Unit Tests: Test individual functions and classes
- Integration Tests: Test VS Code extension integration
- Azure API Tests: Test real Azure Speech Services (requires credentials)
Writing Tests
suite('Voice Configuration', () => {
test('should validate voice settings', () => {
const settings = { name: 'en-US-JennyNeural', style: 'friendly' };
assert.ok(validateVoiceSettings(settings));
});
});
Test Requirements
- All new features must include tests
- Tests should cover both success and error scenarios
- Use descriptive test names and clear assertions
- Mock external dependencies when possible
๐ Internationalization
Adding New Languages
- Create language file:
src/i18n/[locale].ts - Implement the
Messagesinterface - Add locale detection in
src/i18n/index.ts - Update VS Code localization files:
package.nls.[locale].json
Translation Guidelines
- Maintain consistent terminology across languages
- Consider cultural context and conventions
- Use native speakers for review when possible
- Test UI layouts with longer text strings
๐ง Pull Request Process
Before Submitting
-
Test Thoroughly
npm run compile npm run lint npm run test:integration -
Update Documentation
- Update README.md if adding features
- Add/update code comments
- Update CHANGELOG.md
-
Follow Commit Convention
feat: add voice role selection feature fix: resolve audio file naming issue docs: update contributing guidelines refactor: improve error handling logic test: add integration tests for Azure API
Pull Request Checklist
- Code compiles without errors or warnings
- All tests pass
- New features include appropriate tests
- Documentation is updated
- i18n is properly implemented for user-facing text
- No sensitive information (API keys, credentials) is committed
- PR description clearly explains the changes
PR Template
Use our PR template to ensure all necessary information is provided:
- Description of changes
- Type of change (feature, bug fix, etc.)
- Testing performed
- Breaking changes (if any)
- Related issues
๐ Bug Reports
Before Reporting
- Check existing issues to avoid duplicates
- Test with the latest version
- Verify it's not a configuration issue
Bug Report Template
- Environment: OS, VS Code version, extension version
- Steps to Reproduce: Clear, step-by-step instructions
- Expected Behavior: What should happen
- Actual Behavior: What actually happens
- Error Messages: Include any error output
- Sample Text: Provide text that causes the issue (remove sensitive info)
๐ก Feature Requests
Guidelines
- Clearly describe the problem or use case
- Explain the proposed solution
- Consider alternative approaches
- Discuss potential implementation challenges
- Provide mockups or examples if helpful
Feature Categories
- Voice Enhancement: New voice features or customization options
- User Experience: UI/UX improvements
- Performance: Speed or memory optimizations
- Integration: Compatibility with other tools or services
- Accessibility: Features that improve accessibility
๐ Security
Security Guidelines
- Never commit API keys, passwords, or sensitive data
- Use VS Code's secure storage for user credentials
- Validate all user inputs
- Follow secure coding practices
- Report security vulnerabilities privately
Sensitive Information
Files that should NEVER be committed:
test-config.json(contains API keys)*.keyfiles- Environment files with credentials
- Personal configuration files
๐ Code Review
What Reviewers Look For
- Functionality: Does the code work as intended?
- Code Quality: Is it readable, maintainable, and well-structured?
- Performance: Are there any performance implications?
- Security: Are there security considerations?
- Testing: Is the code adequately tested?
- Documentation: Is it properly documented?
Review Process
- Automated checks must pass (CI/CD pipeline)
- At least one maintainer review required
- Address feedback promptly and thoroughly
- Maintain respectful and constructive communication
๐ Recognition
Contributors
We recognize all contributors in our README and release notes:
- Code contributors
- Documentation improvements
- Bug reports and feature requests
- Translations and localization
- Testing and quality assurance
Maintainer Path
Active contributors may be invited to become maintainers based on:
- Quality and consistency of contributions
- Understanding of the codebase
- Community involvement and helpfulness
- Commitment to project goals
๐ Getting Help
Channels
- GitHub Issues: For bugs and feature requests
- GitHub Discussions: For questions and community interaction
- Code Review: For technical guidance during development
Response Times
- We aim to respond to issues within 48 hours
- PRs are typically reviewed within 72 hours
- Complex features may require additional discussion time
๐ Resources
Documentation
Tools
- ESLint for code linting
- Mocha for testing
- VS Code Extension Generator
๐ License
By contributing to Speechify, you agree that your contributions will be licensed under the same MIT License that covers the project.
Thank you for contributing to Speechify! Your efforts help make text-to-speech technology more accessible and useful for everyone. ๐ต