e0640220f2
- installation: one-liner first, what the script does and its overrides, running the generated app, summer new without the script, then the examples/hello walkthrough; the obsolete known-issues callout is gone (D-18) - go modules and workspaces: what summer new writes (relative replace, framework detection order, committed relative go.work, no root go.sum); plugin:add adds a relative go.work path - console scaffolding: Creating an application with --framework, --no-plugin, --no-git, the files written, first commit and naming convention (D-01) - console introduction, llms note in site.yaml, root README quick start
2.8 KiB
title, description, section, order
| title | description | section | order |
|---|---|---|---|
| Console introduction | The two command-line programs of SummerCMS, the summer developer tool and the application binary, and how summer delegates runtime commands. | console | 10 |
Console introduction
WinterCMS has one console entry point, php artisan. SummerCMS has two programs, because the developer tooling and the running application are separate binaries:
| Program | Where it comes from | What it does |
|---|---|---|
summer |
Installed once, by the curl -fsSL https://summercms.io/new | bash -s -- <name> one-liner or from a framework checkout with go install ./cmd/summer. |
Creates, builds and watches applications, scaffolds plugins and their parts, records API parity fixtures and builds these docs. |
The application binary, for example ./bin/acme |
Written by summer build into the application's bin/ directory. |
Runs the application: the HTTP server, migrations, workers, the scheduler, admin accounts and every command its plugins add. |
The application binary is what you deploy, so everything that must run in production, such as migrations and workers, is a command of the binary rather than of summer.
Getting help
Both programs list their commands with --help, and every command accepts --help for its arguments and flags:
summer --help
summer make:model --help
./bin/acme --help
./bin/acme migrate:rollback --help
Commands that summer delegates
During development you often work from the application directory with summer alone. These summer commands find the application's summer.yaml, build bin/<binary> when it does not exist yet, and run the same command of the binary with the same arguments:
| summer command | Runs |
|---|---|
summer migrate |
./bin/acme migrate |
summer migrate:rollback |
./bin/acme migrate:rollback |
summer migrate:status |
./bin/acme migrate:status |
summer serve |
./bin/acme serve |
summer queue:work |
./bin/acme queue:work |
summer queue:clear |
./bin/acme queue:clear |
summer schedule:run |
./bin/acme schedule:run |
summer does not rebuild an existing binary before it delegates. Run summer build after you change code, or keep summer dev running. Every other runtime command, such as route:list, key:generate or admin:create, is run on the binary directly.
The sections of this chapter
- Setup and maintenance lists every command of the application binary.
- Scaffolding covers
summer new,summer build,summer devand themake:commands. - Writing commands shows how a plugin adds its own commands.
- Utilities covers the parity and documentation commands of
summer.