Publishing
Ship your plugin through the Marketplace or on your own.
There are two ways to get a plugin onto someone else's machine:
- The Marketplace — the plugin is reviewed once, then users find and install it from inside Fluxta. This is the path most plugins should take.
- On your own — you hand out a zip and users install it by hand. Useful for a private plugin, an internal tool, or a beta.
1. Fill in the metadata
Publishing needs more from the manifest than development does. Alongside the runtime fields, a publishable plugin carries:
| Field | Requirement |
|---|---|
author | Required. |
license | Must be MIT. |
minAppVersion | Required, and a valid SemVer version. |
maintainers | Required — at least one GitHub username. |
platforms | Required — any of windows, macos, linux. |
categories | Required — one to three categories. |
repository and homepage are optional. Set either to show a link in the
Marketplace; publishing does not require them.
Plugins are MIT-licensed
MIT is the only licence the Marketplace accepts. fluxta create writes it
into the manifest, and there is nothing to change.
fluxta create fills in author, minAppVersion, categories, and
platforms from your answers, writes license as MIT, and leaves
repository, homepage, and maintainers empty.
fluxta publish fills in two of those for you:
maintainers— from the GitHub account you authenticate as, since a CODEOWNERS entry has to be a verified identity.repository— from the package's ownorigingit remote, when neitherrepositorynorhomepageis already set.
Anything still missing at validation time is reported per field. So is any
value left as a TODO placeholder.
minAppVersion declares the oldest Fluxta that can run this plugin. Raise it
when the plugin starts using something new.
2a. Publish to the Marketplace
pnpm build
fluxta publishpublish validates everything, runs the project's own lint and format:check
scripts if it has them, authenticates with GitHub — a one-time browser prompt;
later runs reuse it — and opens a pull request against the public plugin
repository, plugins, adding the plugin's
source under plugins/<your-plugin-id>/. A failing lint or format check stops
it before anything reaches GitHub; run pnpm lint or pnpm format and retry.
Publishing happens after review, not on your machine
fluxta publish opens a pull request. It does not release anything. The
plugin becomes installable only once that pull request is reviewed and merged,
and everything after the merge is automated — you never upload a build
artifact yourself.
Useful flags:
--base <branch>targets a branch other than the repository's default.--warnings-as-errorsfails the command on advisory warnings too.
For the same strict validation with no GitHub interaction at all — in your own
CI, say — use fluxta validate instead.
2b. Distribute it yourself
To hand out a plugin without going through the Marketplace, build a zip:
pnpm build
fluxta package --out my-plugin-1.0.0.zippackage runs the same full publishable validation, then writes a deterministic
archive containing one top-level folder named after the plugin. It refuses to
overwrite an existing file unless --force is passed.
Users install it by unpacking that folder into Fluxta's plugins directory and restarting the app:
| Platform | Location |
|---|---|
| macOS | ~/Library/Application Support/Fluxta/plugins/ |
| Windows | %APPDATA%\Fluxta\plugins\ |
| Linux | ~/.local/share/Fluxta/plugins/ (or $XDG_DATA_HOME/Fluxta) |
The generated project also ships a GitHub Actions workflow for exactly this.
Push a commit that bumps version in manifest.json, and it builds, packages,
tags, and opens a draft GitHub Release with the zip attached, for you to
review and publish by hand. This is independent of
fluxta publish — use either, or both.
After a release
Once the pull request is merged, the release is built and published automatically, and the plugin shows up in the in-app Marketplace. Two consequences are worth knowing while you are still writing code:
- A published version is permanent. Its version number is never reused, even if the release is later withdrawn. Users are offered the newest published version and cannot pick an older one, so a bad release is fixed by publishing a higher version, never by pulling the broken one.
- Compatibility is enforced by the app, not the Marketplace. A plugin that
needs a newer Fluxta than the user has stays visible with its requirement
shown, rather than quietly disappearing. That is what
minAppVersionand the manifest'sapiVersionare for. The one exception isplatforms: a plugin is not listed at all on a system it does not declare, since nothing the user does could make it run there.
Releasing an update
Bump version in manifest.json, rebuild, and publish again. Use SemVer, and
remember that the version shipped last time is frozen — the only way forward is
up.
An update is offered only to users who can run it. If the new version raises
minAppVersion or drops a system from platforms, users it no longer fits keep
the version they have: it stays installed and running, and the Marketplace
shows why the update is not available instead of offering it.