First off, thank you for considering contributing to LaunchTool! It's people like you that make LaunchTool such a great template for the community.
- 🐛 Report bugs - Found a bug? Open an issue
- 💡 Suggest features - Have an idea? Start a discussion
- 📝 Improve documentation - Fix typos, clarify instructions, add examples
- 🔧 Add tool examples - Build new example tools (text tools, converters, etc.)
- 🌍 Add translations - Help translate the template to more languages
- 🎨 Enhance UI/UX - Improve components, accessibility, mobile experience
- 🚀 Share your project - Built something with LaunchTool? Show it off!
# Fork the repo on GitHub, then clone your fork
git clone https://github.com/zenvel/launchtool.git
cd launchtool
# Add upstream remote
git remote add upstream https://github.com/zenvel/launchtool.gitpnpm installgit checkout -b feature/your-feature-nameBranch naming conventions:
feature/add-markdown-converter- New featuresfix/header-mobile-bug- Bug fixesdocs/improve-readme- Documentationrefactor/simplify-config- Code refactoring
- Write clear, readable code
- Follow the existing code style
- Add comments for complex logic
- Test your changes locally
# Run development server
pnpm dev
# Run linter
pnpm lint
# Build to ensure no errors
pnpm buildgit add .
git commit -m "feat: add markdown to HTML converter"Commit message format:
<type>: <short description>
[optional longer description]
[optional footer]
Types:
feat- New featurefix- Bug fixdocs- Documentation changesstyle- Code style changes (formatting, etc.)refactor- Code refactoringtest- Adding testschore- Build process, dependencies, etc.
Examples:
feat: add text case converter tool
fix: resolve mobile menu not closing on route change
docs: improve deployment guide with Cloudflare Pages
refactor: simplify site config structure
# Push to your fork
git push origin feature/your-feature-nameThen open a Pull Request on GitHub with:
- Clear title describing what you changed
- Description explaining why and how
- Screenshots for UI changes
- Testing instructions so reviewers can verify
- TypeScript: Use TypeScript for all new files
- Naming: Use
camelCasefor variables,PascalCasefor components - Imports: Group imports (React, Next.js, components, utils)
- Components: One component per file
- Tailwind: Use Tailwind classes, avoid inline styles
Good example:
"use client"
import { useState } from "react"
import { Button } from "@/components/ui/button"
import { convertMarkdown } from "@/lib/markdown"
export function MarkdownConverter() {
const [input, setInput] = useState("")
return (
<div className="space-y-4">
<textarea value={input} onChange={(e) => setInput(e.target.value)} />
<Button onClick={() => convertMarkdown(input)}>Convert</Button>
</div>
)
}launchtool/
├── app/ # Next.js app router pages
├── components/ # React components
│ ├── ui/ # shadcn/ui components (don't modify directly)
│ └── *.tsx # Custom components
├── lib/ # Utilities and business logic
├── config/ # Configuration files
├── messages/ # i18n translation files
├── content/ # Blog content (MDX)
├── public/ # Static assets
├── docs/ # Documentation
└── scripts/ # CLI helper scripts
When contributing a new tool example:
- Create tool logic in
lib/tools/your-tool.ts - Create UI component in
components/your-tool-card.tsx - Add translations in
messages/en.jsonandmessages/zh.json - Document usage in a new
docs/examples/your-tool.md - Add to README under "Built-in Examples"
Example PR structure:
feat: add JSON to YAML converter
- Adds bidirectional JSON ↔ YAML conversion
- Client-side processing with js-yaml library
- Syntax highlighting for both formats
- Error handling for invalid input
- Translations for EN and ZH
-
Add locale to
config/site.config.ts:locales: [ // ...existing { code: "es", name: "Español", flag: "🇪🇸" } ]
-
Create translation file
messages/es.json(copy fromen.json) -
Translate all keys - use native speakers if possible
-
Update routing in
routing.ts -
Test thoroughly - check all pages render correctly
- Be clear and concise - readers are busy
- Use examples - show, don't just tell
- Add screenshots - especially for UI changes
- Keep updated - if you change code, update docs
While we don't have automated tests yet, manual testing is required:
- ✅ Test on desktop (Chrome, Firefox, Safari)
- ✅ Test on mobile (iOS, Android)
- ✅ Test dark/light themes
- ✅ Test both EN and ZH locales
- ✅ Test with real files/data
- ✅ Check console for errors
Before reporting:
- Check existing issues
- Try the latest version
- Reproduce in a clean environment
When reporting, include:
- Description - What happened vs. what should happen
- Steps to reproduce - Exact steps to trigger the bug
- Environment - OS, browser, Node version
- Screenshots - If applicable
- Console logs - Any error messages
Use the bug report template:
## Bug Description
Clear and concise description of what the bug is.
## Steps to Reproduce
1. Go to '...'
2. Click on '...'
3. Scroll down to '...'
4. See error
## Expected Behavior
What you expected to happen.
## Screenshots
If applicable, add screenshots.
## Environment
- OS: [e.g., macOS 14.0]
- Browser: [e.g., Chrome 120]
- Node: [e.g., 20.10.0]Feature requests are welcome! Please:
- Check discussions first - might already be planned
- Explain the use case - why is this needed?
- Describe the solution - how should it work?
- Consider alternatives - any other approaches?
Start a discussion before writing code for major features.
- Update documentation if needed
- Add yourself to contributors (if first PR)
- Ensure CI passes (once we add it)
- Request review from maintainers
- Address feedback promptly
Reviewers will check:
- ✅ Code follows style guidelines
- ✅ Changes are well-tested
- ✅ Documentation is updated
- ✅ Commit messages are clear
- ✅ No breaking changes (or clearly documented)
- At least one approving review
- All discussions resolved
- CI passes (linting, build)
- Documentation updated
Contributors will be:
- Listed in README.md contributors section
- Mentioned in release notes
- Given credit in commit history
First-time contributors especially welcome! Don't hesitate to ask questions.
We are committed to providing a welcoming and inspiring community for all.
Examples of good behavior:
- Being respectful and inclusive
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
Examples of unacceptable behavior:
- Harassment or discriminatory language
- Trolling or insulting comments
- Publishing others' private information
Violations may result in temporary or permanent ban from the project.
Report issues to: conduct@launchtool.dev
- 💬 Start a discussion
- 📧 Email: hello@launchtool.dev
- 🐦 Twitter: @launchtool
Thank you for making LaunchTool better! 🎉
Every contribution, no matter how small, is valued and appreciated.