anetos tool and app commands reference

Two command lines: the anetos developer tool (module anetos.dev/anetos/cli), which creates projects and writes code, and your application’s binary, which runs the app and its commands. See Commands and Getting started for walkthroughs.

Installing the tool

Flags may come before or after the other arguments. Exit status: 0 on success, 1 on errors, 2 for bad usage.

anetos new <directory>

The directory must not exist or be empty; its name (letters, digits, - and _, starting with a letter) becomes the app’s name. anetos new . uses the current directory. It writes the project, then runs go get for Anetos and the driver (latest) and the anetos tool (its own version), pinned as tools with templ, then go tool templ generate and go mod tidy. With --db=postgres or mysql, create the database before migrate.

anetos dev

Run it in the project (any directory under go.mod). On start and on every change it:

1. runs go tool templ generate (if there are .templ files) and anetos gen,
2. builds the app into tmp/anetos-dev/,
3. stops the previous app (interrupt, then kill after 10 s) and starts the new one with HTTP_ADDR set to a free local port,
4. once the app accepts connections, tells open pages to reload.

Watched: .go (not tests or generated files), .templ, go.mod, go.sum, .env*, and everything under public/; directories starting with a dot, node_modules and testdata, and tmp, vendor, bin and storage at the project’s root are skipped. Requests during a restart wait for the new version. The proxy adds a small script to HTML pages (not htmx responses, HEAD requests or empty responses) that reloads them; build errors, and an app that stops or doesn’t start, show as an error page until the next change. On Linux the app is stopped even if anetos dev is killed.

anetos make:*

Run anywhere in a project. Existing files are never overwritten (make:auth adds one call to setup in main.go).

Names may be BlogPost, blog_post or blog-post; files use snake case.

anetos add <module>[@version] and anetos remove <module>

Install and uninstall plugins, from the project’s directory or below. Both rewrite plugins.go (generated: DO NOT EDIT), which setup passes to ext.Load.

anetos add (version default latest):

1. Prints the module and the version, and that plugins run with the app’s privileges; runs go get <module>@<version>.
2. Adds the package’s Plugin() to plugins.go, after the others, and runs go mod tidy (the module becomes a direct requirement).
3. Runs go build, so a module without a Plugin() ext.Plugin function, or one that doesn’t compile against this version of Anetos, is refused.
4. Runs the built app’s plugins:env (stopped after 2 minutes), which loads the plugins without booting the app: if ext.Load refuses the plugin (its Requires(), its name, its settings’ names), so does anetos add. Otherwise it appends the settings .env.example doesn’t have yet (commented and export keys count as present) under a # <name> plugin line; if the app fails for another reason, it prints the error and keeps the plugin.
5. Prints the next steps: plugins:list, and migrate if it adds migrations. Migrations never run by themselves.

If step 1 to 4 refuses the plugin, go.mod, go.sum and plugins.go are put back as they were (exit 1). When go get upgrades Anetos itself (the plugin requires a newer version), anetos add says so. Adding a module that plugins.go already lists is an error (exit 1). Import names in plugins.go avoid the names package main declares.

anetos remove takes the module out of plugins.go, runs go mod tidy and go build (putting the three files back if one fails, for example because your code still imports the plugin). The plugin’s settings stay in .env and .env.example, and its tables in the database: drop them with a migration of your own if you want them gone (migrate:rollback rolls back a whole batch, your app’s migrations included). Anetos stays at the version anetos add left it at.

anetos lang:add [-from dir] [-version v] [-force] <locale>...

Copies the translations of the framework’s messages for each locale from the module anetos.dev/locales (anetos-dev/locales) into the project’s locales/<locale>/, from the project’s directory or below (v0.3). anetos add lang <locale>... does the same.

1. Downloads the module (go mod download, version -version, default latest), or uses the checkout -from names. The project’s go.mod doesn’t change.
2. Writes framework.yaml (validation messages, error pages, sign-in messages, format and relative), and auth.yaml when the project has locales/en/auth.yaml (make:auth’s pages and emails), without the keys the project’s other catalogs for the locale define (it lists them). A file the project already has is kept, unless -force; an identical one is reported as up to date.
3. Prints the next step: go run . lang:check.

Locale names match the module’s folders regardless of case, and a regional locale matches its language’s folder (bn-BD writes locales/bn/). With no locale, it lists those available. It fails (exit 1), before downloading or writing anything, without a locales folder or for a locale the module doesn’t have. The download runs with GOWORK=off; without network, pass -from.

Other commands

App binary commands

app.Execute() runs the command named by the first argument.

A command other than run and serve runs after app.Boot, with a context from app.Context; app.Close follows, also after a panic. The context is canceled by the first SIGINT/SIGTERM (the command fails with exit 1 if it stops early); the second ends the program. An app runs one command.