How to organize your project folder and file structure

MustSeeMelons
Nov 19, 2019 · 3 min read

The reasoning behind organization

It is a method for dealing with complexity, because our mental processing power is limited and can just process a finite amount of things at once. When thinking on how to separate different entities, we need to create a pattern that will make sense and help us come to conclusions on where should something be put, ideally, subconsciously.

We humans love patterns because we are good with them and that is why their creation in our daily lives can benefit us.

In the case of code, everything starts with a folder bearing the projects name, in which, probably, there is another folder called src .

What are the options?

They are not set in stone, sometimes they could be even mixed together, depends on how large the project is and the preferences of the team.

Completely flat

The easiest way, just placing everything in the same, single folder. Can only be applicable to itsy bitsy projects, for quickly testing something out or learning a new feature, it will start to look like noise very soon, so I would recommend to always make some kind of structure, there is a saying “practice makes perfect” — definitely applies to organization, don’t be lazy.

By feature

We could arrange all of our files to be nested in folders by which feature they belong to:

./scr/
- payments/
- popup/
- api/
- posts/
- api/
- easter-eggs/
- forums/

This approach makes a lot of sense, everything is in its neat place, near where it is used, so nice and tidy.

By type

The idea is that the directory where something should be put is dependent on what it is:

./src
- /api
- /paymentApi
- /postApi
- /components
- /textInput
- /selector
- /containers
- /payments
- /posts

Everything seems clear, and everything has its place, no need to think about where something should go.

Putting it all together

In the real world, it is not so cut and dry and what would make sense in one scenario would be a disaster in another.

The project/file structure should represent its architecture.

Let's look at an example of how to organize our school learning materials. I believe you would agree, that grouping by file type would be a disaster, that is because the “architecture of learning” is split into subjects, which then trickle down into individual topics.

Utter chaos:

/school
- integers.docx
- joan_of_arc.docx
- tectonic_plates.docx
- doing_taxes.docx
- acting_101.docx

Nice and well:

/school
- /math
- integers.docx
- linear-functions.pdf
- /history
- fall_of_rome.epub
- ww2.divx

For a back-end NodeJS project for example it would make sense to group everything by feature:

./src
- /posts
- /api
- /dbService
- /apiHelper
- /dbMapping

While for a front-end project grouping by type would make much more sense:

./src
- /components
- box
- redRectangle
- /container
- login
- home

There is one thing to look out for — deep nesting, it only makes traversal more cumbersome and if you have more places to put something, the decision becomes harder. To be honest, it usually boils down into using a mix of all three mentioned ways, but keeping the architecture in mind certainly helps.

How do you structure your projects? Do you prefer nice and tidy or a sprinkle of chaos?

JavaScript in Plain English

Learn the web's most important programming language.

MustSeeMelons

Written by

JavaScript in Plain English

Learn the web's most important programming language.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade