Eva SarafianouandCursor
b9c2bd733f
* docs: restore generated plugin SDK reference pages Reimplements the Hugo-era plugingodocs/pluginjsdocs/pluginmanifestdocs shortcode pipeline natively in Docusaurus, so the server plugin SDK, web app plugin SDK, and manifest reference pages render full generated content again instead of "Generated content (migrating)" placeholders. Two new Go generators (gen-plugin-godocs, gen-plugin-manifest-docs) and one Node generator (gen-plugin-jsdocs.mjs) read server/public/plugin, server/public/model, and webapp/channels/src/plugins/registry.ts directly from this monorepo and emit gitignored JSON consumed by new PluginGoDocs/PluginGoExample/PluginJsDocs/PluginManifestDocs React components, wired into prestart/prebuild alongside the existing sidebar/OpenAPI generators. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: remove migration plan doc from this PR Was a handoff/status doc for the implementing agent, not meant to ship as part of the change itself. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: make plugin-godocs/manifest-docs builds atomic build:plugin-godocs and build:plugin-manifest-docs redirected straight into data/plugin-*.json, which doesn't exist on a clean checkout (the redirection itself would fail before the generator ever ran) and, on a subsequent failed run, would truncate a previously-good JSON file before failing. Create data/ up front, write to a .tmp file, and only mv it into place once the generator exits successfully. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: fix review findings in plugin doc generators gen-plugin-manifest-docs: - jsonFieldName now excludes unexported fields (matching encoding/json) and falls back to the Go field name when there's no tag or the tag's name component is empty (e.g. json:",omitempty"), instead of dropping the field entirely. - exprTypeDocs's SelectorExpr case now resolves a qualified type only when its package qualifier actually points at the model package (checked against the declaring file's imports), instead of matching any x.Sel identifier by name alone regardless of which package it qualifies. gen-plugin-godocs: - The example-code loop now falls back to example.Code when example.Play is nil (go/doc leaves Play nil when it can't synthesize a whole runnable program), and propagates printer.Fprint errors instead of discarding them. No output change for the current server/public/plugin or server/public/model content — verified via a full regen. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: drop legacy-repo comment references, align jsdocs generator parser Remove "port of the old mattermost-developer-documentation Hugo shortcode" comments from the plugin doc generators/components now that they're fully native to this monorepo, and switch gen-plugin-jsdocs.mjs from the TypeScript compiler API to @typescript-eslint/typescript-estree to match the old script's parser/shape, while keeping the more robust reArg-declared-parameter-name and node-scoped comment-attachment logic. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: bump plugin doc generators' go.mod to go 1.26 go 1.23 was arbitrarily low; align with a current Go version. go run auto-downloads a matching toolchain on older local installs, so this doesn't reintroduce a dependency on server/public/go.mod's version. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: handle RestElement in gen-plugin-jsdocs parameter extraction paramNamesFromPattern silently dropped rest parameters/destructured rest members (e.g. (a, ...rest) or {a, ...rest}), since RestElement matched none of its type checks. No effect on today's registry.ts output (no rest patterns currently used there), but keeps the extraction correct if one is ever introduced. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: simplify plugin doc generators README note Co-authored-by: Cursor <cursoragent@cursor.com> * docs: check stdout write errors in plugin doc generators os.Stdout.Write's return errors were discarded, so a failed/partial write (e.g. broken pipe, disk full) would still exit 0. Combined with the npm scripts' > file.tmp && mv pattern, a truncated write could be treated as a successful generation. Fatal on either write failing. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: flatten Server/Webapp plugin SDK reference sidebar nesting server/server-reference.md and webapp/webapp-reference.md were the only file in their respective folders, so the sidebar generator (which only collapses a folder into a single entry when it has an index.md) rendered them as a "Server" > "Server plugin SDK reference" category with one child instead of one flat entry, unlike every sibling reference folder (rest-api/index.md, bot-accounts/index.md, etc.). Rename both to index.md to match that convention, and update the ~20 cross-referencing links (many with #anchor fragments) that pointed at the old /reference/server/server-reference and /reference/webapp/webapp- reference paths. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
3.2 KiB
title, sidebar_position
| title | sidebar_position |
|---|---|
| Overview | 10 |
Plugins are defined by a manifest file and contain at least a server or web app component, or both.
The Plugin Starter Template is a starting point and illustrates the different components of a Mattermost plugin.
A more detailed example is the Demo Plugin, which showcases many of the features of plugins.
If you'd like to better understand how plugins work, see the contributor documentation on plugins.
Manifest
The plugin manifest provides required metadata about the plugin, such as name and ID. It is defined in JSON or YAML. This is plugin.json in both the sample and demo plugins.
See the manifest reference for more information.
Server
The server component of a plugin is written in Go and runs as a subprocess of the Mattermost server process. The Go code extends the MattermostPlugin struct that contains an API and allows for the implementation of Hook methods that enable the plugin to interact with the Mattermost server.
The sample plugin implements this simply in plugin.go and the demo plugin splits the API and hook usage throughout multiple files.
Read more about the server-side of plugins here.
Web/desktop app
The web app component of a plugin is written in JavaScript with React and Redux. The plugin's bundled JavaScript is included on the page and runs alongside the web app code as a PluginClass that has initialize and uninitialize methods available for implementation. The initialize function is passed through the registry which allows the plugin to register React components, actions and hooks to modify and interact with the Mattermost web app.
The sample plugin has a shell of an implemented PluginClass, while the demo plugin contains a more complete example.
The desktop app is a shim of the web app, meaning any plugin that works in the web app will also work in the desktop app.
Read more about the web app component of plugins here.
Mobile app
Currently there is no mobile app component of plugins but it is planned for the near term.