Thank you for your interest in contributing to the Cap Table Simulator! This document provides guidelines and instructions for contributing.
Be respectful, inclusive, and collaborative. We're building this together for the community.
- Node.js (v18+)
- Git
- Basic knowledge of React and TypeScript
-
Fork the repository on GitHub
-
Clone your fork:
git clone https://github.com/YOUR_USERNAME/cap-table-simulator.git cd cap-table-simulator -
Install dependencies:
npm install
-
Start development server:
npm run dev
-
Create a feature branch:
git checkout -b feature/your-feature-name
Found a bug? Please create an issue with:
- Clear title describing the bug
- Step-by-step reproduction steps
- Expected vs actual behavior
- Browser and OS information
- Screenshots if applicable
Have an idea? Submit a feature request with:
- Clear description of the feature
- Why you think it's useful
- Example use cases
- Any design mockups (if applicable)
- Check existing issues to avoid duplicate work
- Comment on an issue if you want to work on it
- Create a feature branch from
main - Make your changes with clear, descriptive commits
- Test thoroughly - run dev server and verify functionality
- Follow code style - see guidelines below
- Submit a Pull Request with detailed description
Documentation improvements are valuable! You can:
- Fix typos and clarify confusing sections
- Add examples and code snippets
- Improve setup instructions
- Add FAQs based on common questions
- Use strict types - avoid
anyunless unavoidable - Export interfaces for component props
- Use discriminated unions for related types
- Add JSDoc comments for complex functions
Example:
interface ComponentProps {
title: string;
onChange: (value: number) => void;
disabled?: boolean;
}
const MyComponent: React.FC<ComponentProps> = ({ title, onChange, disabled }) => {
// Component implementation
};- Use functional components with hooks
- Keep components focused (single responsibility)
- Extract complex logic into custom hooks
- Use
useMemofor expensive calculations - Export component as default
Example:
const MyComponent: React.FC<MyComponentProps> = (props) => {
const memoizedValue = useMemo(() => {
// expensive calculation
}, [dependencies]);
return <div>{/* component JSX */}</div>;
};
export default MyComponent;- Use Tailwind CSS utility classes
- Follow existing color scheme
- Maintain responsive design patterns
- Use consistent spacing (gap-8, p-6, etc.)
components/
├── FeatureName.tsx (component file)
├── FeatureHook.ts (custom hook if needed)
└── types.ts (types used by component)
App.tsx (main component)
types.ts (shared types)
index.tsx (entry point)
Write clear, descriptive commit messages:
feat: Add pool target input component
- Add slider for pool percentage targeting
- Include health indicators
- Add actionable recommendations
- Support responsive layout
Closes #123
Format:
- Start with type:
feat,fix,docs,style,refactor,test,chore - Brief summary (50 chars max)
- Blank line
- Detailed description if needed
- Reference issues with
Closes #123
-
Update dependencies if needed (
npm install) -
Build and test locally:
npm run build npm run dev
-
Check for TypeScript errors:
# TypeScript checking built into dev server -
Write a clear PR description:
- What problem does it solve?
- How does it solve it?
- Are there any breaking changes?
- Testing done
-
Link related issues:
Closes #123 Related to #456 -
Be responsive to review feedback
- Manual testing: Use the dev server to test your changes
- No breaking changes: Ensure existing features still work
- Edge cases: Test with various inputs and scenarios
- Responsive design: Check on mobile, tablet, and desktop
When you add a feature, please update:
README.md- Add to features list- Component JSDoc - Explain component purpose
CHANGES.mdor phase-specific docs - Document the change- Code comments - Clarify complex logic
main → feature branch → code → PR → merge
main → feature branch → sub-branches for parts → PR → merge
main → bugfix branch → code → PR → merge
- At least one review required
- Address feedback constructively
- Push updates to the same branch
- Rebase and merge when approved
Maintainers will:
- Review PRs regularly
- Test changes thoroughly
- Update version numbers
- Merge to main and publish
- Check existing documentation
- Look at similar components for patterns
- Open a discussion issue
- Comment on related issues
Contributors are recognized in:
- Commit history
- Release notes
- GitHub contributors page
By contributing, you agree that your contributions will be licensed under the MIT License.
npm run dev # Start dev server
npm run build # Build for production
npm run preview # Preview production build
# Check TypeScript (built into IDE)
# Use your editor's TypeScript supportUsing Tooltip:
import Tooltip from './Tooltip';
<Tooltip text="Help text here">
<svg>...</svg>
</Tooltip>Currency Formatting:
const formatCurrency = (value: number) => {
if (value >= 1_000_000) return `$${(value / 1_000_000).toFixed(1)}M`;
if (value >= 1_000) return `$${(value / 1_000).toFixed(0)}k`;
return `$${value.toFixed(0)}`;
};Responsive Grid:
<div className="grid grid-cols-1 lg:grid-cols-2 xl:grid-cols-4 gap-8">
{/* Items here */}
</div>TypeScript errors after changes?
- Check component prop types
- Verify state type correctness
- Ensure imports are correct
Styling not showing?
- Verify Tailwind class names are spelled correctly
- Check responsive breakpoint prefix
- Clear build cache if needed
Component not updating?
- Check dependencies in useMemo
- Verify state updates are correct
- Check memoization logic
Thank you for contributing! Your efforts help make Cap Table Simulator better for everyone. 🙌