Skip to content

build: fizzy's plugins are listed; the minimal shape links two - #6

Open
foxnne wants to merge 2 commits into
mainfrom
build/fizzy-plugin-list
Open

foxnne wants to merge 2 commits into
mainfrom
build/fizzy-plugin-list

Conversation

@foxnne

@foxnne foxnne commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor

Part of fizzyedit/plans#13 (step 1). Goes with fizzyedit/fizzy#441.

What changes

fizzy.buildApp now takes every plugin the app links, fizzy's own among them (fizzy.plugins.text, fizzy.plugins.all). This repo lists them explicitly: the minimal shape links only workbench and text, beside hello and shader (its one region takes documents), and studio and endless link all of fizzy's. The README says so.

Pins fizzy at the merge of fizzyedit/fizzy#441, the first fizzy with fizzy.plugins. Until then, fizzy accepted the old list (one naming none of fizzy's plugins got all of them), so neither repo's CI broke the other. Once this is on main, fizzy drops that fallback.

Verified

  • macOS, at the new pin: this repo's CI builds (each shape, studio as data, and the replay app) all succeed.
  • macOS: fizzy's scripts/check-examples.sh passes all eight builds with this checkout against build: an app lists the fizzy plugins it links fizzy#441's tree (EXAMPLES_DIR, COPYFILE_DISABLE=1). In the minimal build, the generated bundled_plugins.zig imports exactly workbench, text, hello and shader.

🤖 Generated with Claude Code

fizzy.buildApp now takes every plugin the app links, fizzy's among them (fizzy.plugins.*). The
minimal shape links workbench and text beside hello and shader; the others link all of fizzy's.
Needs fizzyedit/fizzy's build/app-plugin-list: the fizzy pin moves to its merge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
foxnne added a commit to fizzyedit/fizzy that referenced this pull request Oct 15, 2026
Part of fizzyedit/plans#13 (step 1).

## What changes

An app built on fizzy chooses which of fizzy's plugins it links.
`fizzy.plugins.{workbench,text,image,archive,markdown,devtools}` are
entries in the list `fizzy.buildApp` takes, beside the app's own, and
`fizzy.plugins.all` is fizzy's own set:

```zig
try fizzy.buildApp(fizzy_dep, &.{
    fizzy.plugins.workbench,
    fizzy.plugins.text,
    .{ .name = "graph", .module = graph_dep.module("plugin") },
});
```

Fizzy's own entries have no module: `build/plugins.zig`'s `link` builds
each one for every executable (native, packaged, web), wired to that
executable's framework, and re-homes the app's modules the way the
native and web builds each did on their own before. Fizzy's build passes
`fizzy.plugins.all` through the same path, so the exe and the web build
no longer keep separate copies of the list. The test build keeps its own
list, because it tests fizzy itself. A plugin that isn't listed doesn't
register, and fizzy's dylib for it (text, markdown, image) is neither
built nor installed.

Two plugins are always built, because fizzy's own code imports them as
libraries. **workbench** must be listed: the editor still holds its
state (`editor.workbench`, the dylib's `arg_c`), and a list without it
fails the build with a message naming the plan. **markdown** is always
compiled, because the store draws READMEs with it, but it only registers
as a plugin when listed.

**Transition:** fizzy's CI builds example-app's `main`, and example-app
pins fizzy by commit, so neither repo can make the change first. Until
example-app lists fizzy's plugins, a `buildApp` list that names none of
them gets all of them first, as before. That fallback is three lines in
`buildApp`, and step 2 removes it. fizzyedit/example-app#6 lists them
explicitly (its minimal shape links only workbench and text), and it
repins to this once merged.

Also:
- `Entry.zig` drops an unused `@import("text")`.
- The `postInit` comment no longer says the bundled plugins don't ship
as dylibs. They do, and it now says why.
- The root `AGENTS.md` describes the list.

Overlaps in files only with the Zig 0.17 drafts (#437, #438), which
touch the whole build; this change touches no build step.

## SDK impact

- [x] None

## Verified

- [ ] macOS: `zig build`, `check-web`, `test`, `test-integration`,
`test-sdk-version`, `check-fmt`. The four built-in dylibs are still
installed to `zig-out/<target>/plugins/`. `scripts/check-examples.sh`
passes against example-app with explicit lists (its minimal shape links
only workbench and text), and against example-app's `main` through the
fallback.
- [ ] Windows:
- [ ] Linux: CI
- [ ] Web: `check-web`

## Follow-ups

- Step 2 (plans#13): a link-only build, and removing the fallback.
- workbench becomes optional once its state moves from the Editor into
the plugin.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The first fizzy with fizzy.plugins, which build.zig now lists.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@foxnne
foxnne marked this pull request as ready for review October 15, 2026 20:07
foxnne added a commit to fizzyedit/fizzy that referenced this pull request Oct 16, 2026
Part of fizzyedit/plans#13 (step 2). Builds on #441.

## What changes

An app built on fizzy can run with linked plugins only:

```zig
const fizzy_dep = b.dependency("fizzy", .{ …, .@"defer-app" = true, .@"dynamic-plugins" = false });
```

(or `zig build -Ddynamic-plugins=false`). In that build:

- **No plugin dylib is built or installed.** fizzy's four bundled ones
are skipped, as are the packaged copies.
- **Nothing loads at runtime.** One comptime constant,
`App.loads_plugins`, turns off:
  - the bundled-dylib probe in `postInit`
  - the user plugins directory scan (`loadUserPlugins`)
  - loading a plugin by id (the store's and settings' enable path)
  - a web page's `?plugin=` request
- **No store.** `PluginStore.register` still sets the `PluginManager`
(settings name plugins through it), then returns before the catalog
fetch and the store's view. `tick` returns at once.

Every gate is comptime, as wasm's are, so a dynamic build checks nothing
at runtime. Most other dynamic paths go quiet on their own when nothing
is `dlopen`ed: the rebuilt-plugin watcher walks only the loaded
libraries.

CI compiles the link-only build on Linux (`-Ddynamic-plugins=false
-Dno-emit`, about 10 s locally), because its gates are comptime and the
default build never compiles that branch.

## SDK impact

- [x] None

## Verified

- [x] macOS:
- **Build:** `zig build -Ddynamic-plugins=false` installs only the
executable, with no `plugins/` directory.
- **Runtime:** a `text.dylib` planted beside the executable and in the
profile's user plugins directory is not mapped into the link-only
process (`vmmap`). The default build, run with the same profile, maps
all four of fizzy's dylibs.
- **Screenshots:** the link-only window has no store icon in the rail,
and the default build has it above the settings cog.
- **Gates on the default build:** `zig build`, `test` (91/91 steps),
`test-integration` (53/53 steps), `check-tests-reached`,
`test-sdk-version`, `check-fmt`.
  - **Web:** `check-web` with and without the flag.
- [ ] Windows:
- [ ] Linux: CI (including the new link-only compile)
- [x] Web: compiles link-only; not run in a browser

Not exercised: opening Settings in the link-only build. Its plugin rows
read through the `PluginManager`, which is set as before.

## Follow-ups

- **Removing the `buildApp` fallback** (a list naming none of fizzy's
plugins gets all of them) waits until fizzyedit/example-app#6 is on
example-app's `main`, because fizzy's CI builds that `main`. It's a
small PR after the repin.
- **example-app: a link-only build** in its CI and in
`check-examples.sh`, after this merges, for the same ordering reason.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant