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

fix(34): WR-11 accept an inline plugins list in plugin:add again

Browse Source 
The comment-keeping summer.yaml edit refused a flow-style plugins list
(plugins: [{id: a, module: b}]) that plugin:add used to handle with a
full rewrite. The edit now replaces an inline list, over one or several
lines, with a block list of its items plus the new ones and keeps every
other line. A list it cannot edit in place (a tagged one, say) falls
back to the full SaveManifest rewrite with a note that the comments were
not kept. plugin:install gets the same behaviour.
This commit is contained in:
Jakub Zych
2026-10-29 22:15:09 +01:00
parent 754ab5423a
commit e6b3aa2222
7 changed files with 168 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/console/scaffolding.md
View File

@@ -86,7 +86,7 @@ summer make:plugin acme.blog
summer plugin:add plugins/acme/blog
```
`summer plugin:add` then registers the local module: it adds the plugin to `summer.yaml`, adds a `require` and a local `replace` to the application's `go.mod`, and adds the directory to `go.work`. The next `summer build` compiles the plugin in.
`summer plugin:add` then registers the local module: it adds the plugin to `summer.yaml`, adds a `require` and a local `replace` to the application's `go.mod`, and adds the directory to `go.work`. The next `summer build` compiles the plugin in. The `summer.yaml` edit appends to the `plugins:` list and keeps the file's comments and blank lines; an inline list (`plugins: [{id: ..., module: ...}]`) is turned into a block list with the new entry. A list in a form it cannot edit in place is written out again with every plugin, and a note says the comments were not kept.
### Upgrading: plugins without a vendor directory

2
docs/plugins/marketplace.md
View File

@@ -104,7 +104,7 @@ summer plugin:install acme.blog --yes
The command asks the registry for the plugin's releases and picks the newest one whose framework minimum the application meets. The application's framework version is the effective one: the newest tag of a local framework checkout when `go.mod` or `go.work` replaces the framework with a directory, otherwise the version `go.mod` requires. `@vX.Y.Z` pins a release, which must meet the framework minimum too. When every release needs a newer framework, the command stops and names the framework version to move to; it never changes the framework requirement itself.
The plugin is installed as a Go module: one `go get <module>@<version>` in the application, then an entry with its ID and package in `summer.yaml`. The edit appends to the `plugins:` list and keeps the file's comments and blank lines. Run `summer build` afterwards: it generates the import, and the new require in `go.mod` loses its `// indirect` marker the next time you run `go mod tidy`. A plugin that is already in `summer.yaml` is not installed again; move it to a newer release with `summer plugin:update`.
The plugin is installed as a Go module: one `go get <module>@<version>` in the application, then an entry with its ID and package in `summer.yaml`. The edit appends to the `plugins:` list and keeps the file's comments and blank lines (an inline `plugins: [...]` list becomes a block list, as with `summer plugin:add`). Run `summer build` afterwards: it generates the import, and the new require in `go.mod` loses its `// indirect` marker the next time you run `go mod tidy`. A plugin that is already in `summer.yaml` is not installed again; move it to a newer release with `summer plugin:update`.
### Required plugins