DenoX CLI: Scaffold Projects and Features Without Losing Control

One of DenoX’s core goals is cutting repetitive development work without taking control from engineers. The framework ships its own CLI as a single TypeScript file that can create projects, generate full features, remove modules safely, and upgrade the framework itself.

Unlike many modern CLIs that pull in dozens of packages, the DenoX CLI leans entirely on native Deno capabilities.

Installation

Install with one command:

deno install -grA -n denox https://raw.githubusercontent.com/olavomello/denox/main/cli/main.ts

Or run it without installing:

deno run -A https://raw.githubusercontent.com/olavomello/denox/main/cli/main.ts new my-shop

The CLI is a self-contained file: no external dependencies and no imports from the framework itself.

Creating a project

Scaffolding a new app is one command:

denox new my-shop

Scaffolding does more than drop a template on disk. It pulls the official starter, strips that starter’s Git history, starts a clean repository, sets the version field back to 0.1.0, clears the changelog, rewrites the README for the new name, and patches denox.config.ts accordingly.

The result is ready to develop against and already clears the project’s deno task ci checks with no manual cleanup.

Custom templates work too:

denox new my-app --template=<repository>

Generating a complete feature

The CLI’s strongest move is generating an entire MVC feature from one command.

denox g feature reviews

Rather than empty placeholders, generation emits a full MVC-shaped API slice: model and DTO, repository interface plus in-memory and Deno KV implementations, service, controller, routes, an OpenAPI description living next to the code, and a skeleton integration test.

Registration into src/api/main.ts happens automatically, so the feature is reachable without hand-wiring.

OpenAPI built in

Every generated feature carries its own OpenAPI description.

Consequences:

• Documentation lives next to the implementation
• Route parity tests keep passing
• Running:

deno task insomnia

regenerates the Insomnia collection automatically.

There is no separate API doc chore to maintain by hand.

Safe code generation

The CLI stays conservative when touching existing code.

When the // denox:features marker is missing or altered, the tool refuses to invent an insertion point.

It still writes the new feature files, prints the precise lines you must paste by hand, and leaves every existing source file alone.

Bad names or duplicate feature ids stop the command before the tree changes.

Removing a feature

The inverse operation matters as much as generation.

denox rm feature reviews

Removal is designed to avoid broken projects.

The CLI first strips every router reference to the feature.

Only after the app is fully disconnected are the files deleted.

Even if the process stops midway, the project is never left with imports pointing at missing files.

When finished, src/api/main.ts matches the pre-generation state: no orphaned imports and no stray blank lines.

Preview first with:

denox rm feature reviews --dry-run

Core modules stay locked. Attempts to delete built-ins — among them auth, users, products, payments, health, and contact — are rejected.

Upgrading the framework

Keep projects current with:

denox upgrade

Upgrades do not overwrite the entire tree. Only framework-owned paths change.

Those paths are listed explicitly in .denox-core.json.

Everything outside that manifest stays untouched, including:

• Generated features
• Project configuration
• Environment files
• Application-specific code

Extra upgrade modes:

denox upgrade --dry-run
denox upgrade --interactive
denox upgrade --ref=v1.2.0

Before upgrading, the CLI checks that the Git working tree is clean. Uncommitted changes abort the operation unless forced, reducing accidental data loss.

Generating pages

The CLI also supports the framework’s file-based routing.

denox g page docs/faq

or

denox g page items/[id]

After the page is created, the routing table regenerates automatically.

Philosophy behind the DenoX CLI

The CLI mirrors the framework: convention over configuration without surrendering control.

Those principles show up as concrete rules: existing files are left alone, hand-edited sources are not rewritten, destructive commands offer --dry-run, framework-owned modules cannot be deleted casually, OpenAPI stays paired with routes, and framework files stay distinct from application code.

Together that yields a small, predictable CLI: less boilerplate, without hiding what changed.