Quick Start

Upgrade Guide

Upgrade an existing GoLazy application from v0.1.11 to v0.1.12.

By Guillermo Alvarez - Published - Updated

Upgrade from v0.1.11

GoLazy v0.1.12 adds object-storage asset uploads, S3-compatible storage, package documentation models, app-versioned CLI handoff, optional tmux development workspaces, and a generated-app service-layout cleanup. Existing v0.1.11 applications do not need a large rewrite.

Update the framework requirement:

go get golazy.dev@latest
go mod tidy

Read Install GoLazy for the current install and module setup flow.

Install or update the matching CLI so lazy new selects the latest sample application template:

curl -fsSL https://golazy.dev/install.sh | sh
lazy --version

Read Run With lazy for the development command and Full App for the generated application layout. The new Development guide collects the mise, service, asset-pipeline, Tailwind, and lazy workflow conventions in one place.

Service package layout

Generated full apps now keep business services in top-level services/, outside the web-facing app/ tree:

services/posts
services/timeservice

Existing applications may keep their current package paths, but new generated apps use the top-level layout. To follow the current template, move packages such as app/services/posts to services/posts and update imports from:

sample_app/app/services/posts

to:

sample_app/services/posts

Read Application Structure and Services And Context.

Asset uploads and S3 storage

Use lazyassets.Registry.Upload when a deployment serves content-hashed assets from object storage, a CDN, or a filer-backed ingress:

if err := appinit.App().Assets.Upload(
    context.Background(),
    storage,
    lazyassets.WithUploadMode(lazyassets.UnpackPermanent),
); err != nil {
    log.Fatal(err)
}

Configure lazyassets.WithBaseURL when rendered asset helpers or importmaps should point at that public asset origin.

Use golazy.dev/lazystorage/s3 for S3-compatible storage such as SeaweedFS. Read Deployment Checklist and Mailers And Storage.

App-versioned CLI commands

App-bound lazy commands now read the current app's golazy.dev requirement and run the matching CLI version from the user cache when the directly invoked binary differs. lazy --version and lazy new still use the binary you invoke directly.

Use this flag only for intentional local CLI testing:

lazy --skip-version-check js

Tmux development workspaces

Apps can add lazy.toml to open a mise-backed tmux workspace with service panes, runner panes, the app development loop, and lazy command-center. This is optional. Existing apps without lazy.toml continue to run the normal development loop.

When adding local service panes, define lifecycle actions as mise tasks named <service>:start, <service>:kill, <service>:create, <service>:migrate, <service>:dump, and <service>:load as needed. <service>:start is required and should run in the foreground.

Development view paths

The public golazy.dev/lazyviews package was removed. Applications should not depend on it. In lazy development builds, the CLI resolves the local view root and passes it to the app through GOLAZY_VIEW_PATH; production builds keep using the embedded view filesystem configured in lazyapp.Config.

Package docs

golazy.dev/lazydoc and lazy docs can inspect local package documentation. This does not require application code changes.

Versioned guide

Use the v0.1.11 upgrade guide when you need the exact upgrade path from v0.1.10 to v0.1.11.