Directus's Initial Folder Structure Makes Me Slightly Uneasy

The first thing that surprises people who install Directus is probably how few configuration folders there are. There are so few that you might think the initial setup failed.

For example, a Node.js-based CMS like strapi has a structure like the following. Even this feels like a fairly simple example.

.
├── build
├── config
├── database
│   └── migrations
├── public
│   └── uploads
├── src
│   ├── admin
│   ├── api
│   └── extensions
└── types
    └── generated

With install-based CMSs, I think it is common to have a structure that includes source folders, config folders, and code containing type definitions. That is because if folders and files are not properly arranged, it is hard to know what to customize and where.

Directus Folder Structure

This is true not only for the Docker version but also for the npm version. For example, suppose you create a new project with a command like the following.

$ npm init directus-project@latest my-app

Then a folder structure like the following is generated under the project folder. There are minimal files such as package.json, but there is really almost nothing.

.
├── extensions // initially empty
└── uploads // initially empty

extensions is the place where extensions installed from the Directus marketplace are stored. Naturally, if you have not installed anything, it is empty. If uploads is intended to upload to S3, it will probably remain empty as well.

Because of that, if you use Directus in a plain state, there is almost nothing for the developer to do. Of course, you can extend functionality by creating extensions.