Folder Structure
| Folder | Description |
|---|---|
| .vscode/ | This is where all your VS Code editor settings live for a project. These are discussed in detail in the VS Code section of this tutorial |
| build/ | Where all the Webpack files live. |
| config/ | The configuration settings for Webpack in each environment (dev, production, etc.). |
| node_modules/ | Local Node packages installed. |
| src/assets/ | Assets like images or fonts can be stored here. Webpack can process these (ie. fingerprinting). For many cases, however, we will try to keep most files inside their respective src/features/ folder so that the project is sliced more vertical and split up by "Business Domain". |
| src/auth/ | Authentication is a cross-cutting feature that all features will need. |
| src/components/ | Any cross-cutting components live here. Read about the "src/features/" folder further down to understand the difference between cross-cutting components and components within a feature. |
| src/constants | A central place to put constants used by the app. This allows for easier updating of things like DEBUG or backend API endpoints. |
| src/directives/ | Any cross-cutting directives live here. |
| src/features/ | These are vertical slices split up by "Business Domain". Aim to keep as many files related to the feature inside a feature folder. This allows teams to more easily split up work and stay within a context. All features can rely on cross-cutting elements (src/auth, src/components, src/directives, etc.) or other features. Features should not access sub-parts of other features directly. They need to use the public API of the other feature or else move an internal part out into a cross-cutting folder. The src/components/ folder, for example, holds components that don't really belong with any feature or make up a feature on their own. You may decide to duplicate a component instead (because being "DRY" is not necessarily always beneficial). |
| src/http/ | Contains the non-auth HTTP functionality (for making any non-auth HTTP calls with Axios). Also contains the router and routes/end-points for the app. If the routes file becomes too congested, you could split up the routes and import them from their respective src/features/ folders. This is just a matter of preference though. |
| src/store/ | This is the central storage for the app, using Vuex. |
| src/styles/ | Global styles go here. Local styles should go inside the correct src/features/ folder. |
| src/utils | General shared utilities can go here. Anything specific to a feature should reside in the src/features/ folder for it. |
| static/ | Any files that you don't need processed through Webpack. |
| test/ | Unit and E2E test cases. |
In some projects you'll see a pages/ folder and a components/ folder. However, I suggest bringing these together and arranging vertically based on your business domain (ie. foo/) instead of horizontally by file type. You don't have to be perfect on your grouping at first, but over time you will adjust as your business domain matures. As it matures you will better organize and slice it. You end up with a project that is easier to split up into separate projects/teams if you feel the project has become too large and complex. Context switching can also be reduced since related files (related by business/what feature they support) live a little closer to each other.
This type of structure lives individually from your routing. Your routes (external API) can change independently from your (internal API) business domain organized into feature folders.
Since some operating systems don't have case-sensitive file naming, the kebab-case is used for all file names.
