Project Directory Structure: Assets
There isn’t one right answer when it comes to a project’s directory structure, especially if it’s a solo project, but it is important if everyone is on the same page. In this article, I’ll explain the purpose of the assets directory in the context of the projects I work on.
By definition, everything in the project is an asset. What I mean by “assets” could be succinctly expanded to “front-end assets.”
Having a separate assets directory can help keep the front-end development and build dependencies separate from the main body of the project. This is especially valuable in Node.js projects, where you might pollute your node_modules directory with thousands of unnecessary dependencies in production where the assets have been pre-built or built once during the deployment of that release.
Source and Dist
I assume the direct descendents of my assets directory to be the source. I could be explicity by putting a src or source directory underneath the assets, but I usually dont.
The build step is going to release the distributable front-end assets, which could be placed in a dist directory that is a direct descendent of the assets, but it might be placed elsewhere. In a Hugo project, for example, the front-end assets would build to the public directory located one-level above the assets. In a Node.js project, they might build to a dist directory underneath assets while a handler searches for those assets in place. It just depends on the project. It’s good to be flexible in this regard.
- The assets directory is a place for front-end assets.
- Children of that directory are source, or static.
- The build stack for assets is also relegated to this directory.
- The dist ends up where it makes sense for that type of project.