fractal-file-structuring

Use a fractal tree structure: name files in kebab-case, treat each file as a mini-library with named exports, and split large files into same-named folders holding private implementation files. Place shared code in the nearest shared folder covering all current consumers.

Create a same-named folder next to the component file and move private pieces such as sub-components and helpers into it. Only the root file imports from its subtree, keeping it as the public API boundary while the folder holds the implementation.

No. This approach forbids index.ts, index.tsx, index.js, and index.jsx files. Prefer explicit file entry points with meaningful names, and if a subtree needs a public entry point, name that file after the concept it exposes.

Place shared helpers in the nearest shared folder that covers all current consumers, as deep in the tree as possible. Do not move code to a high-level shared folder based on speculative future reuse; move it later if usage changes.

Co-locate unit tests next to the file they cover, such as foo.test.ts beside foo.ts. Tests for private extracted files sit next to those files, though testing through the public mini-library is preferred when coverage is sufficient.

Avoid broad components, hooks, utils, types, or services folders unless absolutely necessary. If they exist, they must only be imported from by files named components.ts, hooks.ts, and so on, preserving the mini-library boundary pattern.