golem15/summercms
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(build): mark scaffolded files with //summer:make and pass the app to generated commands (quick-261028-pq8)

Browse Source 
- model, migration, command, job and admin-controller stubs start with
  //summer:make <kind>; registry.gen.go keeps its generated-code header
- the registry scan accepts the directive and the older header
- command functions may take one *backpack.App; generatedCommands takes a
  variadic app, so plugin.go files calling generatedCommands() still compile
- scaffolded plugins keep the app from Boot and return generatedCommands(p.app)
- make:command notes the nil app for an older plugin.go
- docs, help text and the blog example follow
This commit is contained in:
Jakub Zych
2026-10-28 19:04:39 +01:00
parent a95a014b52
commit 70e4b4183c
18 changed files with 355 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/console/writing-commands.md
View File

@@ -6,7 +6,7 @@ order: 40
---
# Writing commands
A plugin adds console commands to the application binary the way a WinterCMS plugin calls `registerConsoleCommand`. In SummerCMS a command is a plain `bonfire.Command` value, and the plugin returns its commands from `pact.HasCommands`. `summer make:command acme.blog Publish` generates a starting point in `console/publish.go`.
A plugin adds console commands to the application binary the way a WinterCMS plugin calls `registerConsoleCommand`. In SummerCMS a command is a plain `bonfire.Command` value, and the plugin returns its commands from `pact.HasCommands`. `summer make:command acme.blog Publish` generates a starting point in `console/publish.go`: a `PublishCommand(app *backpack.App) bonfire.Command` function. A command that needs the database, the config or a service another plugin publishes reaches it through `app`, for example with `backpack.App.Lookup`.
## Defining a command
@@ -50,7 +50,7 @@ if err := catalog.Call(context.Background(), "blog:publish", args, os.Stdout); e
Return the commands from the plugin's `Commands` method, which implements `pact.HasCommands`. The generated `main` appends every plugin's commands after the framework's runtime commands. Command names must be unique: when two commands share a name, or a command is named `list` or `help`, `bonfire.NewRoot` fails with `bonfire.ErrDuplicateCommand` naming the command, and the binary does not start. Keep your commands in your plugin's own namespace, such as `blog:`. The global options are reserved as well: a flag named `verbose`, `quiet`, `ansi`, `no-ansi`, `no-interaction`, `env` or `help`, or with the shorthand `v`, `q`, `n` or `h`, makes `bonfire.NewRoot` fail with `bonfire.ErrReservedFlag`.
A scaffolded plugin's `Commands` method returns the generated list of everything in `console/`, so commands created with `summer make:command` are registered without editing `plugin.go`.
A scaffolded plugin keeps the application in `Boot`, and its `Commands` method returns `generatedCommands(p.app)`, the generated list of the commands in `console/`, so commands created with `summer make:command` are registered without editing `plugin.go`. The list holds every function in a file that starts with `//summer:make` that returns a `bonfire.Command` and takes no parameter or a single `*backpack.App`; the generated code passes it the application. `Commands` is collected after `Boot`, so the application is set by then. A command function with other parameters is returned from `Commands` by hand. In an older `plugin.go` that calls `generatedCommands()` without the application, the generated functions receive `nil`; `summer make:command` prints a note when it finds that call.
## Output