Quick Start
Upgrade Guide
Upgrade an existing GoLazy application from v0.1.11 to v0.1.12.
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.