As a frontend developer, having a consistent and scalable project structure helps me stay productive and maintain code quality. Here’s a breakdown of how I structure my React projects using Vite, TypeScript, Tailwind CSS, and modern tools like ESLint, Prettier, and Docker.
📁 Folder Structure Overview
Here’s a typical folder structure I use:
/public → Static assets like images, icons, SVGs
/src
├─ @types/ → Global TypeScript declarations
├─ components/ → Reusable UI components
├─ constants/ → Static configuration or key-value constants
├─ data/ → Static or mock data
├─ features/ → Feature-based modular folders (e.g. auth, dashboard)
├─ fonts/ → Custom fonts (if any)
├─ hooks/ → Reusable custom React hooks
├─ i18n/ → Internationalization logic
├─ pages/ → Route-level components
├─ routes/ → App route definitions
├─ services/ → API calls or service functions
├─ store/ → State management (Redux, Zustand, etc.)
├─ types/ → Local shared types
├─ utils/ → Utility/helper functions
├─ App.tsx
└─ index.css
Root
├─ .env → Environment variables
├─ .env.example → Template for environment variables
├─ .eslint.rc → ESLint config
├─ .prettierrc → Prettier config
├─ tailwind.config.js → Tailwind config
├─ tsconfig.json → TypeScript base config
├─ tsconfig.node.json → Extended config for tools
├─ vite.config.ts → Vite config
├─ dockerfile → Docker setup
├─ docker-compose.dev.yml → Docker services (e.g., backend, db)
├─ yarn.lock / package-lock.json
⚙️ CI/CD & Tooling Setup
✅ Linting & Formatting
ESLint with TypeScript & React plugins for code quality.
Prettier for consistent formatting.
Husky for Git hooks (e.g., lint before commit).
EditorConfig to maintain consistency across editors.
🚀 CI/CD
GitHub Actions (or similar) for:
Build checks
Lint checks
Deployment (e.g., Vercel, Netlify, or Docker container build)
🌍 Environment Management
.env and .env.example are included at the root.
Used for:
Base URLs
API keys
Feature flags
Never commit sensitive .env files, use .gitignore.
🧱 Folder Naming Conventions
Plural folders for grouping: components, hooks, services.
PascalCase for components (LoginForm.tsx), camelCase for files like hooks/utilities (useAuth.ts, formatDate.ts).
Feature folders are self-contained:
/features/auth/
├─ AuthForm.tsx
├─ authService.ts
├─ authSlice.ts
🐳 Docker Support
Dockerfile and docker-compose.dev.yml make local setup easy.
Useful when you want to standardize dev environments across machines or collaborate with backend teams.
🔧 Tailwind + PostCSS + Vite
tailwind.config.js and postcss.config.js are at the root.
Vite ensures blazing fast dev builds and a simpler setup compared to CRA or Webpack.
✅ Why This Structure?
Modular: Easy to maintain, even as the app scales.
Consistent: Clear naming and separation of concerns.
Team-friendly: Easy for others to contribute without confusion.
Deployment-ready: CI/CD + Docker + env support included.
This structure has evolved over time with real-world experience. While there’s no one-size-fits-all, this approach works great for mid-to-large scale React projects using modern tooling.
🚀 Ready to Improve Your React Setup?
If you found this structure helpful, consider giving it a try in your next project.
Have a structure you swear by? Or want feedback on your current setup?
Let’s chat in the comments
Image credit https://undraw.co/
Top comments (3)
yeah this breakdown hits home tbh, i tried so many structures myself - curious, you think iterating on folder setup or solid process actually matters more for team speed?
I'm glad the breakdown resonates with you. In my experience, both folder structure and process play crucial roles, but I’d say solid processes tend to have a bigger impact on team speed overall. Having a consistent workflow and clear guidelines helps the team stay aligned and work efficiently, even if the folder structure isn't perfect. That said, a good folder structure can certainly support better process by making the codebase more intuitive and easy to navigate. It’s about finding a balance that works for your team’s needs. Especially in the early stages of a project, creating a rigid structure can sometimes slow the team down. Opting for a more flexible and simple structure at the start can allow for faster prototyping.
Thank you. I'd love to chat more. Feel free to reach out anytime, whether it’s about development or anything else you're interested in.