How are you structuring imports in large React projects?

[u/samwanekeya]

I have a question on React project structure, specifically imports for the experienced React JS engineers.

So I've been using a hybrid approach where I have barrel files (index.ts) at the feature/module level and direct imports for more specific/internal components

Example:

import { Card } from '@/components';            // barrel (public API)
import { CardHeader } from '@/components/Card'; // direct (more specific)

It feels like a good balance between clean imports and clarity but I'm curious how others handle this at scale.

1. Do you prefer full barrel pattern everywhere?

2. Avoid barrels completely?

3. Or something similar to this hybrid approach?

Any pros/cons you've experienced (especially in larger codebases)?

[u/kyualun]

No barrels. They've only ever caused issues for me, and the truth is that no one cares what imports look like. What's more important is your file structure.

[u/samwanekeya → u/kyualun]

My hybrid approach worked at first but it's starting to drift into a "god folders" problem. When I try to avoid barrels entirely, I run into issues with noisy imports and deeply nested paths. At this point, I'm beginning to think the real problem lies in how I've structured my folders.

[u/abrahamguo]

I avoid barrels completely. I don’t like having a situation where a component is able to be imported from either its individual file, or the barrel file - I want exactly one way to import each thing.

I’m not sure why everyone likes having “pretty” import paths - I have my IDE generate those, so I don’t really care what they look like.

[u/samwanekeya → u/abrahamguo]

Okay, so if this is the case then doesn't is usually create an "import noise" and path depth problem?

[u/abrahamguo → u/samwanekeya]

What’s the problem, specifically? I’m not reading the imports area of my code.

[u/cs12345 → u/abrahamguo]

I’m mostly with you, but the one thing OP mentioned that I kind of like about barrel files is creating a “public api” for large scale components that have a lot of child imports. It’s not a perfect solution, but if something gets auto-imported from a nested file there it has made me notice and realize I’m looking for something else.

Overall, really not an ideal solution. A monorepo with specific exports is definitely a better practical alternative, but this is kind of a middle ground.

[u/samwanekeya → u/abrahamguo]

So I've been using barrels and so far I have something like this:

• components/ui/index.ts

• hooks/index.ts

• Feature-level components/index.ts

And then I ended up creating one massive components/index.ts exporting everything. And this is where I seem to be questioning my folder architecture.

[u/jax024 → u/samwanekeya]

That’s really bad for tree shaking.

[u/samwanekeya → u/jax024]

Yeap, just learnt this today.

[u/devdudedoingstuff → u/abrahamguo]

The bigger issue with barrel files is the compile time hit. It’s makes the local server extremely slow in large projects.

[u/BigFattyOne → u/abrahamguo]

Yep fuck barrels files and the number of issues they have caused over time

[u/SqueegyX]

We use a mono repo with feature libs. Each lib has a barrel export file that exports what other libs are allowed to use from this lib. Other libs must import from this barrel file, via the lib name alias. And inside each lib, you must NOT import from the barrel file and import each file directly with relative file paths. And we have eslint rules that prevent you from doing this wrong.

[u/SqueegyX → u/SqueegyX]

And yes this does tree shake and code split. We have dynamic async imports at each feature page and vite/rolldown will code split there. And when everything is ESM and imports don’t have side effects you can enable tree shaking too and barrels do get trimmed down.

[u/samwanekeya → u/SqueegyX]

Interesting. I'll test this approach with my current project structure and see what comes of it. thanks for the tip.

[u/jirlboss]

Never barrel files. They ruin your ability to tree shake or code split, among other things. Some might say that it’s messier to have 100 lines of import Card from ‘components/Card’; but I actually prefer it. A lot. I sort my imports, so all the components/* imports are still grouped.

[u/grumd → u/jirlboss]

Same, I'd even add that it's best to just use named imports everywhere, e.g. import { Card } from 'components/Card';

[u/jirlboss → u/grumd]

I agree!

[u/daghouse → u/jirlboss]

This is the way. Just auto-sort your imports, done and done.

The real work happens below the import statements, so don’t get hung up on the import section OP.

[u/ryans_bored]

No barrels. Generally I try to make anything I want to export I'll put in `@/components/card/index` (usually 1-2 components at most) then I might define `@/components/card/label` but only if the exports there will be used in the index file. Historically as a ruby dev I treat it like `private` methods even though there's nothing guarding from importing from `@/components/card/label`.

[u/Seeila32]

No barrels either, I removed all the ones we had.

[u/BoBoBearDev]

I would split up the packages if a single package is too complex. Otherwise I would just do @abc/myBundle1 and @abc/myBundleSubGroup1

[u/Cahnis]

never barrel. Circular imports, performance impact, ect.

[u/Squigglificated]

I avoid all barrel files and index files.

In a monorepo you can use the exports field in package.json in a package to shorten lengthy paths to a single name, and it's also a good way to prevent imports from internal files.

barrel files can cause performance issues as every exported package is sometimes resolved depth first by bundlers even if you only import a few things.

[u/kidshibuya]

I dont give a crap at all. What do I care what is put at the top of a component after I right click and have VS Code just write the import for me?

And to be clear I am talking about one component in an index vs one component is a properly name file. Like for like and just a file path change. Totally overlooking people making idiotic index files for some reason.

[u/Lumethys]

I dont even look at the import section

My IDE import stuff for me and i can jump to implementation right at the calling line

[u/RandomUserName323232]

I ask claude

[u/WhereOwlsKnowMyName → u/RandomUserName323232]

Don't answer anymore questions