mevn-cli: a scaffolder for Mongo, Express, Vue and Node applications

A generator for the four-part MEVN stack

MEVN is an acronym for MongoDB, Express.js, VueJS and Node.js, and mevn-cli is a command line tool for getting started with that combination. The stated job is to offer a boilerplate template plus utilities for building a MEVN stack based webapp, and to take away the hassle of setting up a local development environment, which the README describes as a nightmare for people who are just starting out.

The audience is stated plainly: developers who want to focus on writing actual code rather than assembling four frameworks by hand. This is a scaffolder, not a framework, and the difference shows in how the tool is shaped. It generates a project directory and then stays available for the repetitive parts of a workflow, which is why the command list includes dependency installation, component generation, containerisation and deployment rather than just an init.

The repository structure follows a conventional Node package layout: src/ for the source, bin/ for the executable entry, scripts/ for the preinstall helper, jest/ and __e2e__/ for tests, docs/ for the documentation site, plus babel.config.js, gulpfile.js, jest.config.js, .eslintrc.js and commitlint.config.js at the root. The documentation site is built with VuePress through the docs:dev and docs:build scripts.

Eight commands covering the whole build-to-deploy path

The command set is the clearest statement of what the tool believes a full stack developer needs. The README lists them in a table.

mevn init scaffolds a MEVN stack project in the current path. mevn serve serves the client and server side template locally. mevn add takes a list of dependencies and an optional --dev flag, adding them on the go. mevn generate creates component files for the client and a CRUD boilerplate template for the server based on MVC architecture. mevn codesplit lazy loads components as required. mevn dockerize serves the webapp as multi-container Docker applications. mevn deploy deploys the webapp to a cloud service of choice. mevn info prints debugging information about the local environment.

Two of those deserve a second look, because they are where the tool adds the most beyond a project generator. mevn generate is not a Vue-only component generator, it also produces a server-side CRUD template following MVC, so the data layer and the API layer are scaffolded together with the views. mevn info exists because scaffolding tools break in different ways on different machines, and printing the environment is the fastest way to diagnose a mismatch.

One entry is deliberately vague. mevn deploy says it deploys to a cloud service of choice, and the README does not list the providers it supports, so you should treat that command as needing its own investigation before you rely on it.

Quickstart: a global install and one init

The installation is the standard npm global install, and the prerequisites are the three tools you would expect: npm as the package manager, node.js as the runtime, and git for version control.

npm install -g mevn-cli
mevn init <appname>

After that, the generated project is yours to run and edit. The npm package registers the command as mevn, with bin/mevn.js as the executable and the package main, and it ships only the bin and lib directories, so a global install gives you the command and nothing else in your project.

The install step is worth reading twice before you run it in a locked down environment. package.json defines a preinstall script that runs node scripts/preinstall.js and a postinstall that runs opencollective-postinstall. A global npm install therefore executes code from the package before you type a single mevn command, and that behaviour is normal for npm packages of this vintage rather than a sign of anything unusual, but it is a fact about the tool rather than a detail to discover later.

ES6 modules, Babel and a gulp build

The generated project is described as being written in modules thanks to ES6 syntax, which the README presents as a readability and compactness benefit for the boilerplate it produces. The tool itself follows the same conventions: the source lives in src/, Babel transpiles it, and gulp drives the build.

The npm scripts show the workflow a contributor or an interested user would follow:

    "build": "gulp",
    "build:watch": "babel --watch src --out-dir lib --copy-files --include-dotfiles",
    "lint": "eslint ./src __e2e__ jest",
    "test": "jest",

The build output lands in a lib directory, which the contributing guide describes as the transpiled ES5 code, and the watch script rebuilds that directory as files change. The lint step covers src/, the end to end suite and the jest helpers, and the test script runs jest with lint as a pretest, so lint failures block the test run rather than being a separate chore.

The runtime dependencies explain the character of the tool. commander handles the command parsing, inquirer handles the interactive prompts, execa runs the child processes that do the real work, ora shows spinners, envinfo backs mevn info, and update-notifier keeps the user aware of newer published versions.

Husky hooks, Commitlint and the conventional commit format

The contribution workflow is strict, and for a good reason: the generated output has to look like it came from one tool. The guide asks contributors to fork and clone, make their changes, run npm run build, run npm link so the mevn root command is available locally, and run the tests locally with npm test before committing.

The mechanics are enforced by tooling rather than by review. Husky is configured with a pre-commit hook running lint-staged and a commit-msg hook running commitlint, so a commit that fails the conventional commit format is rejected before it reaches the branch. Commitlint checks the messages against the standard pattern, where the type is required, the scope is optional, and the body and footer are optional. The examples in the README show the shape, including a breaking change footer for a change that affects users.

Two housekeeping rules are easy to miss. Contributors are asked to remove any dummy files or add them to .gitignore, and the repository has a CODE_OF_CONDUCT.md alongside the contribution guidelines.

The npm release and the repository are five years apart

Here is the fact that should shape any adoption decision. The npm package version is 1.8.3, and the tagged releases are v1.8.3 dated 2021-02-28, v1.8.2 dated 2020-10-22 and v1.8.1 dated 2020-08-23. The last push to the repository was on 2026-08-20, on the develop branch.

That gap has two consequences. Anyone who installs with npm install -g mevn-cli gets the 2021 artefact, whatever has happened in the repository since, and the repository's own contributing guide notes that changes not in a release yet can be seen in the commit history or by building from source. A second consequence is the dependency set: commander 6, inquirer 6, execa 4, chalk 2 and a Vue CLI era toolchain, in a world where the surrounding ecosystem has moved on.

The default branch being develop rather than main is a related warning sign. The published package is the artefact anyone actually installs, and it is old.

The alternative to a generator like this is to assemble the same stack by hand from the individual pieces, or to use a single-framework scaffold and wire the rest yourself. The difference in approach is what the trade is about: mevn-cli bundles all four layers including the database connection and CRUD templates, so a beginner gets a running application immediately, and a team with existing conventions gets a project that already violates them and has to be rewritten.

Editorial conclusion

Adopt mevn-cli if you want a MEVN skeleton with MongoDB, Express, Vue and Node already wired together and you are starting from scratch rather than extending an existing codebase. Do not adopt it as a maintained foundation for a long lived product: the newest npm release is 1.8.3 from February 2021 while the last push to the repository was on 2026-08-20, and the dependency set is built around the Vue CLI era. Verify three things first: what the global install actually executes, since package.json runs a preinstall script and an opencollective postinstall; which Vue version mevn init generates and whether it matches the Vue you intend to use; and how far mevn deploy, described only as deploying to a cloud service of choice, goes without your own provider configuration. The licence is MIT, the package installs as mevn-cli and the command is mevn.

Frequently asked questions

Official sources

1. License: MIT
2. madlabsinc/mevn-cli on GitHub
3. Project website
4. README
5. Releases