How do you approach folder structure in a large frontend application?

Question

Accepted Answer

Folder structure significantly impacts developer productivity and code discoverability. There are two main approaches, each with distinct trade-offs.

Feature-based structure groups all code related to a feature together. For a user profile feature, you would have a folder containing the components, hooks, utilities, tests, and types specific to that feature. This approach excels in large applications because developers work primarily within a single folder when building or modifying features. It also makes code deletion safer since feature boundaries are clear.

Layer-based structure groups code by technical type. All components go in a components folder, all hooks in a hooks folder, all services in a services folder. This approach works well for smaller applications and makes it easy to find code by type. However, it creates friction in large applications because a single feature change may require touching many folders.

A hybrid approach combines both strategies. Shared infrastructure like utilities, design system components, and API clients live in technical folders. Feature-specific code lives in feature folders. This balances discoverability with modularity.

Regardless of approach, establish clear conventions. Define what constitutes a feature versus a shared module. Document where new code should go. Use barrel files or index files consistently to control public APIs. Enforce boundaries through linting rules or module boundaries tooling.

The key insight is that folder structure is a communication tool. It should make the codebase's organization obvious to any developer exploring it.