Generate ESLint, Prettier, Husky, Vitest, GitHub Actions, Docker and security configs for your existing project — without copy-pasting boilerplate.
Detects |
50 modules across 10 categories. Pick exactly what you need or run a preset — DevFlow detects your stack and generates configs that match it.
Husky, lint-staged, Commitlint and Commitizen — conventional commits enforced on every commit, with the hook installed on every clone.
Husky moduleESLint flat config, Prettier and EditorConfig — rule sets derived from the dependencies in your package.json, not from a copied template.
ESLint moduleVitest or Jest with the right environment for your stack, plus Testing Library setup and the npm scripts to run them.
Vitest moduleGitHub Actions, GitLab CI, Codecov, Dependabot and Renovate — a pipeline that lints, type-checks, tests and builds on every pull request.
GitHub Actions moduleMulti-stage Dockerfile with a non-root user, a docker-compose file for local runs and a .dockerignore that keeps the build context small.
Docker moduleNx, Turborepo and pnpm or yarn workspaces, with a shared tsconfig.base.json and the workspace scripts to run them.
Monorepo moduleDevFlow is a workflow generator. It does not scaffold applications, and it is not a build system. Here is the honest picture, including the column where DevFlow has nothing to offer.
| Capability | DevFlow CLI | Manual setup | create-* CLI | Nx / Turborepo |
|---|---|---|---|---|
| Adds the workflow to an existing repository | Yes | Yes | No — it creates the project | Partially |
| Adapts config to the detected stack and package manager | Yes | By hand | One stack only | Partially |
| Git hooks, commit validation, lint-staged | Yes | By hand | Rarely | No |
| CI workflow that lints, type-checks, tests and builds | Yes | By hand | Rarely | No — you write the pipeline |
| Dockerfile, compose file and .dockerignore | Yes | By hand | Sometimes | No |
| Task graph, build caching, generators | No | No | No | Yes — this is the core feature |
| Reproducible across every repository | Yes | No — copy-paste drifts | Only for new projects | Yes |
| Applies to a repository you already have | Yes | Yes | No | No |
Nx and Turborepo are not alternatives to DevFlow — they own the task graph and the cache. Read DevFlow vs Nx and DevFlow vs Turborepo for the detail, or DevFlow vs manual setup for the cost breakdown.
A preset is a pre-selected module list that adapts to the detected stack. The counts below are for a single Node.js/TypeScript repository: React, Next.js and Vue projects get Testing Library on top, and monorepos swap release-it for Changesets and add the workspaces module.
The four things every repository needs on day one.
When: A single repository, a small team, or a repository that already has linting.
Minimal plus linting, testing, CI/CD and a pinned toolchain.
When: The default for a new repository, and the right choice for most teams.
Recommended plus end-to-end testing, releases, security and containers.
When: A service that ships to production and is maintained by more than one person.
The wizard asks for a preset, and the presets reference lists every module in each one. The visual builder produces the exact command for your stack.
Run one command. DevFlow walks you through four simple steps — no manual config, no copy-pasted boilerplate.
Three different ways to use DevFlow — the wizard, a preset, or direct flags. Whichever fits your workflow.
Skip the wizard. Use --husky, --lint, --test, --ci, --docker and --only to add exactly the modules you want from a script or a CI pipeline.
CLI flags and examplesMinimal, Recommended or Full, adjusted for the detected stack and repository type. Run npx create-devflow --all for an opinionated setup in one command.
Compare the three presetsEvery generated file is created with skip-if-exists semantics, so an existing eslint.config.mjs is never replaced. Run it again after a new module lands and only the missing pieces are added.
How detection and re-runs workThe objections that come up before anyone runs the tool — answered with the real behaviour of the CLI, including the parts that are not automatic.
No. Every configuration file is created with skip-if-exists semantics, so an existing eslint.config.mjs, .prettierrc.json, .husky/pre-commit or any other generated file is left untouched. DevFlow does rewrite package.json, but it only merges: existing scripts are never replaced, and new scripts are added alongside them.
Yes. The package manager is detected from the lock file (pnpm-lock.yaml, yarn.lock, bun.lockb or package-lock.json) or the packageManager field, and the install command, CI workflow and Dockerfile are all generated for the detected manager. Use --pm pnpm, --pm yarn or --pm bun to override detection.
Yes. Run npx create-devflow --ci github to generate only .github/workflows/ci.yml, or use --only <module> to select any single module. Every module can be applied on its own.
DevFlow has no --undo flag, but everything it writes is plain text in your repository. Delete the generated files listed on each module page, remove the scripts it added from package.json, and remove the devDependencies it installed. Running the tool in a clean git checkout and reviewing the diff is the safest way to see exactly what changed.
Yes. A project with the next dependency is detected as a Next.js stack, which means DevFlow generates the React + TypeScript ESLint flat config and the React Testing Library setup. The same config works for both the App Router and the Pages Router, because DevFlow does not add framework-specific Next.js ESLint plugins that would be tied to a router.
Yes. The monorepo category contains Nx, Turborepo and workspace modules, and a project with nx.json or turbo.json is detected as a monorepo. DevFlow generates the nx.json or turbo.json configuration and the turbo scripts. The generated CI workflow is a single-repository pipeline, so monorepo caching and affected-only runs are covered in the Turborepo CI guide.
Add --dry-run to any command, for example npx create-devflow --dry-run for the wizard or npx create-devflow --all --dry-run for the recommended preset. DevFlow then prints the execution plan — files to create, packages to install and scripts to add — and writes nothing to disk.
Yes. DevFlow is MIT licensed, published on npm as create-devflow, and the full source is available on GitHub. There is no paid tier, no telemetry and no account required.
Node.js 18, 20 and 22. The package declares node >=18.0.0 in its engines field, and the generated CI workflow runs on Node.js 20 by default.
DevFlow runs on macOS, Linux and Windows through WSL2. It is a Node.js CLI with no native binary dependencies, and the generated files use POSIX-style paths and LF line endings.
It is a workflow generator. DevFlow does not create your application — it adds the development workflow to a repository that already exists: Git hooks, linting, formatting, testing, CI/CD, Docker and security configuration. That is why it can be run safely inside an existing project.
No. DevFlow only writes configuration files, adds npm scripts and installs dev dependencies. It never touches files under src/ except for the Testing Library setup file and the Mock Service Worker handlers, both of which are new files.
Copying works, but the copied config is usually not adapted to the target stack, the package manager or the CI provider, and it silently drifts as the tools are upgraded. DevFlow regenerates the configuration from the detected project context, so the same command produces a correct result in a pnpm monorepo and in an npm single-package repository.
Read the code that writes your config, open an issue when a module is missing, or star the repository if it saved you an afternoon.
One command reads your stack, your package manager and your repository type, then writes the configuration that fits — as plain files in your repository, so you can review and edit every line.