Thank you for your interest in contributing to the FFXI Progress Tracker! This document provides guidelines and information for contributors.
- Search existing issues before creating new ones
- Use the bug report template with detailed reproduction steps
- Include screenshots for UI-related issues
- Provide browser/OS information for compatibility issues
- Check the roadmap to see if it's already planned
- Use the feature request template with clear use cases
- Explain the problem you're trying to solve
- Consider implementation complexity and maintenance burden
- Fix typos and improve clarity
- Add examples to existing documentation
- Update outdated information
- Translate content (if multilingual support is added)
- Write tests for new features
- Improve test coverage for existing code
- Add edge case testing
- Performance testing for large datasets
- Bug fixes with corresponding tests
- New features following our architecture
- Performance improvements
- Accessibility enhancements
- Node.js 18+ (LTS recommended)
- Yarn package manager
- Git for version control
- VS Code (recommended) with our extensions
-
Fork the repository
# Fork on GitHub, then clone your fork git clone https://github.com/YOUR_USERNAME/ffxi-tracker.git cd ffxi-tracker
-
Install dependencies
yarn install
-
Set up your development environment
# Copy VS Code settings (recommended) cp .vscode/settings.json.example .vscode/settings.json # Start development server yarn dev
-
Verify your setup
# Run tests to ensure everything works yarn test:run # Check linting yarn lint # Verify TypeScript compilation yarn type-check
- Find a good first issue labeled
good-first-issue - Comment on the issue to let others know you're working on it
- Create a feature branch from
main - Make your changes following our code standards
- Test your changes thoroughly
- Submit a pull request
Follow our git workflow standards:
feat/feature-name # New features
fix/bug-description # Bug fixes
refactor/component-name # Code refactoring
docs/documentation-update # Documentation changes
test/test-description # Adding or updating tests
chore/maintenance-task # Maintenance tasks
Use Conventional Commits format:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Examples:
feat: add character portrait picker
fix: resolve tab navigation keyboard accessibility
docs: update installation instructions
test: add unit tests for Button component-
Create a feature branch
git checkout -b feat/your-feature-name
-
Make your changes
- Follow our code standards
- Add tests for new functionality
- Update documentation if needed
-
Test your changes
yarn test:run # All tests pass yarn lint # No linting errors yarn type-check # No TypeScript errors yarn build # Builds successfully
-
Commit your changes
git add . git commit -m "feat: add amazing new feature"
-
Push and create PR
git push origin feat/your-feature-name # Create PR on GitHub
- Use strict TypeScript configuration
- Prefer
typeoverinterfacefor object shapes - Define prop types outside component definitions
- Use proper typing for all functions and variables
// โ
Good
type ButtonProps = {
variant?: 'primary' | 'secondary';
size?: 'sm' | 'md' | 'lg';
onClick?: () => void;
};
const Button: React.FC<ButtonProps> = ({variant = 'primary', size = 'md', onClick}) => (
<button className={buttonVariants({variant, size})} onClick={onClick}>
Click me
</button>
);- Use
React.FCwith const arrow functions - Sort props alphabetically in parameters and JSX
- Use implicit return for JSX-only components
- Follow JSX formatting rules for spacing and structure
// โ
Good - Implicit return for JSX-only
const SimpleCard: React.FC<SimpleCardProps> = ({children, className, title}) => (
<div className={cn('card-base', className)}>
<h3>{title}</h3>
{children}
</div>
);
// โ
Good - Explicit return when logic is present
const ComplexCard: React.FC<ComplexCardProps> = ({data, loading}) => {
if (loading) return <LoadingSpinner />;
return (
<div className="complex-card">
{data.map(item => (
<div key={item.id}>{item.name}</div>
))}
</div>
);
};Imports are automatically sorted by ESLint:
// React imports first
import {useState, useEffect} from 'react';
// External packages
import {createClient} from '@supabase/supabase-js';
// Internal packages (@/ prefix)
import {Button} from '@/components/ui/button';
// Relative imports
import {formatDate} from '../utils/date';- Use tailwind-variants for component styling
- Follow design system tokens and naming
- Maintain accessibility standards
- Support responsive design
const buttonVariants = tv({
base: 'inline-flex items-center justify-center rounded-md font-medium transition-colors',
variants: {
variant: {
primary: 'bg-primary text-primary-foreground hover:bg-primary/90',
secondary: 'bg-secondary text-secondary-foreground hover:bg-secondary/80',
},
size: {
sm: 'h-9 px-3 text-sm',
md: 'h-10 px-4',
lg: 'h-11 px-8',
},
},
defaultVariants: {
variant: 'primary',
size: 'md',
},
});- Colocate tests in
__tests__folders - Test user behavior not implementation details
- Use descriptive test names
- Mock external dependencies
// Component tests
describe('Button', () => {
it('should render with correct variant classes', () => {
render(<Button variant="primary">Click me</Button>);
expect(screen.getByRole('button')).toHaveClass('bg-primary');
});
it('should call onClick when clicked', () => {
const handleClick = vi.fn();
render(<Button onClick={handleClick}>Click me</Button>);
fireEvent.click(screen.getByRole('button'));
expect(handleClick).toHaveBeenCalledOnce();
});
});- Aim for 80%+ coverage on new code
- Test critical paths thoroughly
- Include edge cases and error scenarios
- Test accessibility features
yarn test # Run tests in watch mode
yarn test:run # Run tests once
yarn test:ui # Run tests with UI
yarn coverage # Generate coverage report- Collection-focused design optimized for large datasets
- Accessibility first - WCAG 2.1 AA compliance
- Mobile responsive design patterns
- Consistent visual hierarchy
- Reusable components with clear APIs
- Flexible styling through variants
- Proper state management
- Error handling and loading states
- Search existing issues for duplicates
- Try latest version to see if it's already fixed
- Check documentation for expected behavior
- Test in different browsers if UI-related
**Bug Description**
A clear description of what the bug is.
**Steps to Reproduce**
1. Go to '...'
2. Click on '...'
3. See error
**Expected Behavior**
What you expected to happen.
**Screenshots**
If applicable, add screenshots.
**Environment**
- OS: [e.g. macOS, Windows]
- Browser: [e.g. Chrome, Firefox]
- Version: [e.g. 1.0.0]- Check the roadmap for planned features
- Search existing requests for similar ideas
- Consider implementation complexity
- Think about maintenance burden
**Feature Description**
A clear description of the feature you'd like to see.
**Problem Statement**
What problem does this solve?
**Proposed Solution**
How would you like this to work?
**Alternatives Considered**
Other solutions you've considered.
**Additional Context**
Screenshots, mockups, or other context.- GitHub Issues - Bug reports and feature requests
- GitHub Discussions - General questions and ideas
- Code Reviews - Pull request feedback
- All PRs require review before merging
- Be respectful in feedback
- Focus on code quality and maintainability
- Test thoroughly before approving
- Bug reports: 1-3 days
- Feature requests: 1 week
- Pull requests: 2-5 days
- General questions: 1-2 days
All contributors are recognized in:
- README.md contributors section
- Release notes for significant contributions
- GitHub contributors page
- First-time contributors get special mention
- Significant features credited in release notes
- Bug fixes acknowledged in issue closure
- Documentation improvements highlighted
By contributing to FFXI Progress Tracker, you agree that your contributions will be licensed under the MIT License.
Your contributions help make FFXI Progress Tracker better for the entire community. Whether you're fixing a typo, reporting a bug, or adding a major feature, every contribution matters!
Happy Contributing! ๐ฎ