fearless: a Vue 3 and TypeScript dashboard scaffold

A scaffold, and the todo list that says so

fearless is described as a dashboard scaffolding based on Vue.js 3.x and TypeScript created by Vite, and the author is zce, with a live preview at fearless.zce.me.

What makes it readable as a project rather than a demo is the todo list at the top of the README, and it is honest about what is not there. Three items are open: CRUD demos, data virtualization, and more demos. Data virtualization in particular is the one that a dashboard with a large table eventually needs, and its absence tells you the sample data sets are small.

The feature list, by contrast, is long and specific, and it is the reason to look at the project.

The modern Vue.js ecosystem with vue 3.x, pinia 2.x and vue-router 4.x. Full strong typing with TypeScript 5.x. Next generation frontend tooling with Vite 5.x. HTTP requests based on the Fetch API, with ky 0.x and the note not axios. A customizable UI library in naive-ui 2.x. A complete engineering workflow with eslint 8.x, husky 7.x, lint-staged 11.x and commitlint 13.x. A locally mocked API server on express 4.x. Authorization with an access token, a refresh token, an auth refresh token and role based authorization. And modern application deployment through GitHub Actions and Vercel with serverless functions.

The last two are what turn a component playground into a scaffold for an application with users.

The stack, and the opinions hidden in it

The package.json shows the actual versions, which is where the real constraints live. The runtime dependencies are vue 3.4.15, vue-router 4.2.5, pinia 2.1.7, naive-ui 2.37.3, the Ionicons set at 0.12.0, and ky at 1.2.0. The dev dependencies are TypeScript 5.3.3, Vite 5.0.12, vue-tsc 2.0.0, eslint 8.56.0 with the Vue plugin, prettier 3.2.4 using a shared configuration, express 4.18.2, and the Vite Vue and Vue JSX plugins.

Two choices are worth calling out because they are opinions rather than defaults. The HTTP client is ky, which is a small Fetch wrapper, and the README is explicit that it is not axios, so a team arriving with axios habits will be reading a different API. And the type checking is done with vue-tsc, with the build script running the type check and the Vite build together through npm-run-all2, so a type error fails the production build rather than only the editor.

The lint script is unusually thorough in what it passes, listing .vue, .js, .jsx, .cjs, .mjs, .ts, .tsx, .cts and .mts extensions, with a fix flag and the .gitignore respected so that generated files are not linted.

There is a small drift between the README and the manifest. The README describes ky as 0.x while the manifest requires 1.2.0, and it describes TypeScript as 5.x and Vite as 5.x, which do match. The ky line is the one to trust the manifest on.

The mock server starts itself, because it is a Vite plugin

The Mock API Server section is short and contains the most useful operational detail in the README. The built-in mock server starts as a Vite plugin, which means you do not need to start it alone.

That is a design decision with real consequences for the development loop. A separate mock server would be another process to start, another port to keep track of and another thing to break when the port is taken. Folding it into the dev server means one command gives you the front end, the hot reload and the API, and the front end code can be written against a real HTTP contract from the first line.

The repository layout supports that reading. There is a mock/ directory and a mock.http file, which is the format used to describe the mocked endpoints, and a separate api/ directory, which is the boundary the front end code is expected to call. The .env.development and .env.production files sit at the root next to an env.d.ts, so the environment is typed and the base URL differs per environment.

For a scaffold, this is the part that saves the most time. A front end written against the mock contract works unchanged when the real api/ directory is implemented behind it, and the type declarations travel with the project.

The authorization flows, and the three accounts to try

The Authorization feature has four entries in the README: an access token, a refresh token, an auth refresh token, and role based authorization.

The last two are what turn a login form into an application model. The refresh token lets a session outlive its access token, the auth refresh token covers the case where the refresh token itself needs renewing, and role based authorization means the UI can hide what a user may not do, and the mock server can enforce it.

The online preview is where you can see that working, and the README publishes the credentials, with an owner account zce and password zce, an admin account jack with password 123, and a staff account pony with password 123. Three roles across several demo accounts, and the difference between them is what you would see in a deployed product.

Publishing the credentials for a demo is fine. It is worth remembering that this is a scaffold rather than a hardened application, and that the role checks in the front end are for demonstration until the server enforces them.

Scaffolding a project and running it

There are two ways in, and the first one is not the repository.

The recommended path is to create a new application with caz, the author's own scaffolding tool, and the README gives the commands:

# create apps through this
$ npx caz vue#next my-app
# enter generated directory
$ cd my-app

Cloning the repository directly is the alternative, and the sequence is clone, install, then work:

# clone repo
$ git clone https://github.com/zce/fearless.git
$ cd fearless

# install dependencies
$ pnpm install # or npm install

The scripts are minimal. The dev script runs Vite with hot reload at http://localhost:3000, and the build script produces a production build with minification:

# dev with hot reload at http://localhost:3000
$ pnpm dev # or npm run dev

# build for production with minification
$ pnpm build # or npm run build

The prerequisites are Node.js 18.17 or newer with 20.x preferred, and the package manager field pins pnpm 8.15.5, though the README says npm works as well.

Where fearless is the wrong choice

The first wrong-tool case is a public product. The scaffold makes choices that suit an internal dashboard, an unauthenticated preview, a small team and a mock data set, and the open todo list says so. The role checks in the front end are a demonstration until the server enforces them, and the mock API is not a contract.

The second is a team with an existing component library. naive-ui, the icon set and the whole layout are part of the template, and swapping a UI library in a scaffold is a rewrite of every view rather than a configuration change.

The third is a project that needs a specific data layer. The package includes Pinia, and a team with a preference for a different state approach will be replacing it in the code that the template was written around, which is the main cost of using a scaffold at all.

There is also a versioning point. The manifest pins eslint 8, Vite 5, TypeScript 5.3 and pnpm 8, and the README's own feature list describes the same generation of tools, so the scaffold is a snapshot of early 2024 tooling. Adopting it means adopting that generation, or doing the upgrade work yourself, and the vite and eslint majors are the two that have moved on since.

MIT, a private package, and a project with a public demo

The project is licensed MIT, with the LICENSE file at the root and the copyright line reading MIT and zce. The package itself is marked private with a version of 0.2.0, which is the correct setting for a scaffold, since nobody installs it from a registry, they clone it or generate it with caz.

The repository layout is a modern Vue project with the usual separation. There are three TypeScript configurations, tsconfig.json, tsconfig.app.json and tsconfig.node.json, which keeps the app and the build tooling typed separately. There is a vite.config.ts, a vercel.json for the serverless deployment path, an index.html, a public/ directory for static assets, and a src/ directory for the application.

The continuous integration is GitHub Actions, and the contributing section is a conventional fork, clone, branch, commit, push and pull request sequence, with one note worth heeding: be sure to merge the latest from upstream before making a pull request. The author uses a shared prettier configuration from the same organisation, which is why the formatting is consistent across the author's projects.

For an adopter, the practical sequence is to use caz rather than cloning, so that the generated project is the current template, to run the dev server once to see the mock data and the three roles, and then to replace the mock/ directory with the real api/ contract before writing any screen.

Editorial conclusion

Adopt fearless if you are starting an internal dashboard with a Vue background and want the wiring, the mock server and the auth flows already in place, and treat it as a starting point to edit rather than a framework to depend on. Do not adopt it for a public product, because the project itself lists CRUD demos, data virtualization and more demos as unfinished, and do not expect its choices, such as ky over axios and naive-ui, to be free to change later without touching the code. Before you build, check the dependency versions in package.json against the ones the README describes, since the ky major version differs, and read the mock/ directory, because that is where the API contract your front end will be coded against actually lives.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zce/fearless on GitHub