What's New in Vandor v0.4

What's New in Vandor v0.4

Vandor v0.4 is a ground-up rethink of how Go backend projects should be built. The core idea has not changed -- Domain-Driven Design, hexagonal architecture, infrastructure on demand -- but the execution is sharper, the workflow is faster, and the tooling is significantly more capable.

Here is everything that is new.

Core-First Development Model

This is the big one. In v0.4, every project starts with the core -- your business domain, configuration, and logger. Nothing else. No HTTP server, no database, no cache. Those arrive later, through VPKG, only when you actually need them.

This is not just a philosophical stance. It changes how you think about your project:

• You design your domain before choosing infrastructure
• Your domain logic is testable from day one, without mocking infrastructure
• You can build CLI tools, workers, or event processors with the same foundation

# Start with just your domain
vandor new --module github.com/acme/myapp --tidy auto
vandor add context catalog identity

# Add infrastructure when the time comes
vandor vpkg add @official/http-humachi
vandor vpkg add @official/entgo

New CLI Commands

The CLI has been redesigned for clarity and consistency.

vandor new

Replaces the old vandor init. Creates a new project with the core-first structure.

vandor new --module github.com/acme/myapp --tidy auto

vandor add context

Replaces the old vandor add domain. The name change reflects what contexts actually represent: bounded business capabilities, not database tables.

vandor add context catalog identity order

vandor add usecase and vandor add service

Scaffold use cases and domain services within a context:

vandor add usecase catalog create_product list_products
vandor add service identity auth_service

vandor dev:app and vandor run:app

Built-in development and production runners. No external task runner required.

# Development with hot reload
vandor dev:app

# Production
vandor run:app

8 Official VPKG Packages

v0.4 ships with 8 official packages covering the most common backend needs:

All official packages are designed to work together, tested as part of the release process, and maintained by the Vandor team.

vandor vpkg add @official/http-humachi @official/entgo @official/atlas

Actions and Aliases

Packages in v0.4 do more than install code. They provide actions -- commands for scaffolding, code generation, and package-specific operations.

# Run an action from a package
vandor vpkg exec official/http-humachi add-handler
vandor vpkg exec official/entgo add-schema
vandor vpkg exec official/atlas migrate-diff

To make this more ergonomic, v0.4 introduces aliases -- project-level shortcuts for the actions you use most:

# Same thing, shorter
vandor add:http-handler
vandor add:schema
vandor migrate:diff

Aliases are just syntactic sugar over vpkg exec. You can always use the full form.

Non-Interactive CLI by Default

v0.4 flips the default interaction mode. Commands are non-interactive by default -- you pass your arguments directly on the command line. This makes scripts, CI/CD pipelines, and quick workflows faster.

# Non-interactive (default)
vandor add context catalog identity order

# Interactive mode when you want it
vandor add context -it

This also means commands are more predictable. You always know what will happen before you run something.

Runtime Independence

This was true in earlier versions, but v0.4 makes it explicit: your compiled Go application has zero dependency on the Vandor binary. Vandor is a development tool. In production, you deploy a standard Go binary.

# Build
go build -o bin/app ./cmd/app

# Deploy -- no Vandor needed
./bin/app

No framework runtime, no CLI dependency, no special binary requirements. Just your Go code.

Typed Configuration with Runner Model

v0.4 introduces a structured configuration system:

config/
  base.yaml           # Shared across all runners
  runner/
    app.yaml           # App-specific overrides
    worker.yaml        # Worker-specific overrides

Different runners (vandor run:app, vandor run:worker) load the base config and merge their runner-specific overrides. This replaces the old single-file configuration approach and makes it straightforward to run the same codebase as different deployment targets.

Sync Contract

The sync system in v0.4 treats your filesystem as the source of truth. When you run vandor sync, it reads the directory structure -- your contexts, use cases, and services -- and regenerates the *_gen.go wiring files.

Key guarantees:

• Only *_gen.go files are written during sync
• Your hand-written code is never modified
• Every vandor add command triggers an automatic sync
• You can preview changes with vandor sync --check

# Sync everything
vandor sync all

# Preview without applying
vandor sync --check

Doctor Diagnostics

New in v0.4: the vpkg doctor command inspects your project and reports problems with installed packages, configuration, and wiring.

# Check for issues
vandor vpkg doctor

# Auto-fix what can be fixed
vandor vpkg doctor --fix

The doctor checks for missing configuration values, out-of-sync Go module dependencies, broken wiring, and other common issues. Think of it as a health check for your project's infrastructure layer.

Package Tiers

VPKG packages are now organized into three tiers:

• Official (@official/) -- Maintained by the Vandor team, tested with each release
• Verified (@verified/) -- Community-contributed, reviewed for quality
• Community (@community/) -- Community-contributed, use at your discretion

This tier system helps you assess the quality and maintenance level of packages before installing them.

Summary

Vandor v0.4 is a cleaner, faster, more capable version of the tool. The core-first model, the 8 official packages, the actions/aliases system, and the non-interactive CLI come together to create a workflow that gets out of your way and lets you focus on your domain.

If you are new to Vandor, start with the Getting Started guide. If you are upgrading from an earlier version, the new CLI commands and project structure will feel familiar -- just sharper.