Contribution Guidelines
Thank you for your interest in contributing to Excalidraw! This guide will help you make meaningful contributions that align with the project’s standards.Getting Started
Finding Work
- Check the Roadmap: Browse the project roadmap to see planned features
- Start Small: New contributors should begin with issues labeled Easy
- Claim an Issue: Comment on an issue to have it assigned to you by a maintainer
- Discuss First: For major changes, open an issue to discuss your approach
Before You Start
- Read the Development Setup guide
- Understand the Project Architecture
- Review existing code to understand patterns and conventions
Pull Request Process
1. Create a Branch
Create a descriptive branch name:2. Make Your Changes
Follow the coding standards outlined below.3. Write Tests
Add tests for your changes:- New features: Add comprehensive test coverage
- Bug fixes: Add a test that would have caught the bug
- Refactoring: Ensure existing tests still pass
4. Run Quality Checks
Before committing, ensure your code passes all checks:5. Commit Your Changes
Commits are automatically linted via the pre-commit hook. If the hook fails, fix the issues and commit again.6. Write a Good Pull Request Title
Use semantic prefixes for your PR title:- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Code style changes (formatting, whitespace, etc.)
- refactor: Code changes that neither fix bugs nor add features
- perf: Performance improvements
- test: Adding or updating tests
- build: Build system or dependency changes
- ci: CI/CD configuration changes
- chore: Other changes that don’t modify src or test files
- revert: Reverts a previous commit
7. Provide a Clear Description
In your PR description:- What: Describe what you changed
- Why: Explain why the change was needed
- How: Briefly describe your approach
- Testing: Mention how you tested the changes
- Screenshots: Include screenshots/videos for UI changes
- Related Issues: Link to related issues using
Fixes #123orCloses #456
8. Test in Staging
Each PR automatically deploys a staging environment. Always test your changes in staging, especially:- Cross-browser testing for UI changes
- Performance testing for large features
- Mobile responsiveness
9. Wait for Review
Some automated checks require maintainer approval before running. They’ll show as:- A maintainer will review your PR
- They may request changes or ask questions
- Make requested changes in new commits
- Once approved, a maintainer will merge your PR
Coding Standards
TypeScript
- Use TypeScript: All new code should be TypeScript
- Strict Mode: We use strict TypeScript configuration
- Type Safety: Avoid
anytypes; use proper type definitions - Explicit Types: Add return types to functions
- Interfaces: Prefer
interfaceovertypefor object shapes
React
- Function Components: Use function components with hooks
- Props Types: Define explicit prop types
- Hooks: Follow Rules of Hooks
- Memo: Use
React.memo()for expensive components - Keys: Always provide stable keys in lists
State Management
- Jotai: Use Jotai atoms for state management
- Atomic: Keep atoms small and focused
- Derived State: Use atom getters for computed values
- Selectors: Create selectors for complex state access
Performance
- Memoization: Use
useMemoanduseCallbackappropriately - Virtualization: Virtualize long lists
- Lazy Loading: Code-split large features
- Debounce/Throttle: Rate-limit expensive operations
Naming Conventions
- Files:
camelCase.tsxfor components,camelCase.tsfor utilities - Components:
PascalCasefor component names - Functions:
camelCasefor function names - Constants:
SCREAMING_SNAKE_CASEfor constants - Types/Interfaces:
PascalCasefor type definitions - Private: Prefix internal functions with underscore:
_internalHelper
Code Organization
- File Length: Keep files under 500 lines; split if necessary
- Function Length: Keep functions focused and under 50 lines
- Imports: Group imports logically (React, third-party, internal)
- Exports: Use named exports; avoid default exports for utilities
Comments
- When: Comment “why” not “what”
- Complex Logic: Explain non-obvious algorithms
- TODOs: Use
// TODO: descriptionfor future work - JSDoc: Document public APIs
Error Handling
- Try-Catch: Wrap risky operations in try-catch
- User-Facing: Show user-friendly error messages
- Logging: Log errors for debugging (development only)
- Graceful Degradation: Fail gracefully when possible
Accessibility
- Semantic HTML: Use appropriate HTML elements
- ARIA: Add ARIA attributes where needed
- Keyboard: Ensure keyboard navigation works
- Focus: Manage focus for modals and dialogs
- Color Contrast: Maintain WCAG AA contrast ratios
Testing Standards
See the Testing Guide for comprehensive testing guidelines.Package-Specific Guidelines
Working on packages/excalidraw/
- Public API: Changes affect npm package consumers
- Breaking Changes: Avoid breaking changes; discuss with maintainers
- Documentation: Update API docs for public API changes
- Size: Be mindful of bundle size; check with
yarn build:esm
Working on excalidraw-app/
- App-Specific: These features are for excalidraw.com only
- Collaboration: Test collaboration features with collab server
- PWA: Ensure offline functionality still works
- Analytics: Don’t add tracking to self-hosted Docker builds
Working on Internal Packages
- Shared Code: Changes affect multiple packages
- Pure Functions: Keep utilities pure when possible
- Dependencies: Minimize external dependencies
- Tests: High test coverage required
Localization (i18n)
Adding Translations
- Translations are managed via Crowdin
- Don’t submit PRs with translations; use Crowdin instead
- To add a new language, open an issue
- Languages must reach 85% completion to be included
Using Translations in Code
Documentation
Code Documentation
- Public APIs: Document with JSDoc comments
- Complex Functions: Add description and parameter docs
- Types: Document complex type definitions
User Documentation
Don’t submit PRs to update user documentation unless explicitly asked. The docs team manages user-facing documentation separately.Communication
Where to Ask Questions
- Issue Comments: Ask questions on the relevant issue
- Discord: Join the Discord community for general discussion
- Discussions: Use GitHub Discussions for longer-form questions
Be Respectful
- Be patient and respectful to maintainers and other contributors
- Assume good intent in feedback
- Focus on constructive criticism
- Help others when you can
Common Pitfalls
Avoid These Mistakes
- Skipping Tests: Always write tests for your changes
- Not Running
yarn fix: This causes CI failures - Large PRs: Break large changes into smaller, focused PRs
- Ignoring Reviews: Address all review comments
- Breaking Changes: Discuss breaking changes before implementing
- Forgetting Type Checks: Run
yarn test:typecheck - Not Testing in Staging: Always test in the staging deployment
Recognition
All contributors are recognized in:- GitHub contributor list
- Release notes for significant contributions
- The project’s gratitude and appreciation!
Questions?
If you have questions about contributing:- Check existing documentation
- Search closed issues for similar questions
- Ask on Discord
- Open a discussion on GitHub
Next Steps
- Review the Testing Guide to write effective tests
- Browse the roadmap to find something to work on
- Join the Discord community to connect with other contributors