As applications grow, consistency becomes increasingly important.
Without clear conventions, every developer structures files slightly differently, names things differently, and introduces small variations that slowly make the codebase harder to navigate.
Vuesion uses generators to automate these conventions.
The goal is not to generate complete features.
The goal is to generate a consistent starting point.
Generators create the files that every new feature requires while leaving the actual implementation to the developer.
Rather than repeatedly creating the same folders, imports, and boilerplate, generators establish a predictable project structure from the beginning.
They automate structure, not decisions.
Generators build upon the Prisma schema.
A typical workflow looks like this:
Design
│
▼
Prisma model
│
▼
Generator
│
▼
Implementation
The data model defines the language of the feature.
Generators then create the surrounding application structure.
Vuesion currently provides generators for:
Each generator focuses on one stage of the development process.
Rather than generating an entire feature at once, developers generate only the parts they need as development progresses.
The component generator creates the files required for a new component.
A generated component includes:
VueButton.vue
VueButton.stories.ts
VueButton.spec.ts
This encourages every component to start with:
instead of adding those later.
The API generator creates the foundation for a new backend endpoint.
Depending on the current project structure, this may include:
The generated files provide the surrounding architecture while leaving the business logic to be implemented manually.
The store generator creates the client-side structure required for communicating with the backend.
This typically includes:
Because generators share the same conventions, multiple generators may contribute to the same file rather than creating duplicate definitions.
For example, shared interfaces may already exist because they were generated by another stage.
The page generator creates a new Nuxt page using the conventions established throughout the project.
Depending on the selected options, it can configure:
This allows new pages to immediately fit into the existing application architecture.
Generators only create missing files.
If a file already exists, it is skipped.
This makes generators safe to run repeatedly without risking existing implementations.
Developers remain fully in control of every generated file.
Generators are not only intended for starting a project.
They are typically used whenever a new stage of a feature begins.
For example:
New feature
│
▼
Prisma model
│
▼
API generator
│
▼
Store generator
│
▼
Component generator
│
▼
Page generator
Each stage receives the same consistent foundation before implementation begins.
One of the primary goals of the generators is maintaining consistency.
As teams grow, different developers naturally introduce different naming conventions, folder structures, and implementation styles.
Generators reduce these differences by creating the same starting point every time.
The resulting codebase feels as though it was written by a single developer rather than assembled from many individual styles.
Generators eliminate repetitive work without introducing another abstraction layer.
Every generated file is plain application code.
Developers are expected to read it, modify it, and extend it as the feature evolves.
Nothing is hidden behind generated APIs or custom runtime behavior.
The architecture remains fully visible.
Generators should not replace software design.
They should automate the repetitive parts of software development while allowing developers to focus on solving domain problems.
Vuesion generators provide:
The result is a codebase that scales more predictably while preserving the flexibility of handwritten application code.
Continue with Why Vuesion Exists to learn the ideas and principles that shaped the architecture of Vuesion.