Documentation Index
Fetch the complete documentation index at: https://mintlify.com/excalidraw/excalidraw/llms.txt
Use this file to discover all available pages before exploring further.
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