logseq-plantuml-js-plugin (MVP)

Renders PlantUML diagrams in Logseq using PlantUML's pure-JavaScript (TeaVM-compiled) engine — no server, no JVM, no network call, source never leaves the device. This is the proof-of-concept described in docs/LOGSEQ_INTEGRATION.md in the main PlantUML repo (C:\github\plantuml, a sibling of this folder), built as an actual loadable plugin rather than just a writeup. This is a standalone project on purpose — a Logseq marketplace submission needs its own repo anyway (see below), so it isn't nested inside plantuml/.

It deliberately mirrors the existing cofcool/logseq-plantuml-plugin (slash command → child block with a ```plantuml fence → a "Render" button via a {{renderer ...}} macro) so that, if this goes anywhere, it can plug into that plugin as a second backend rather than asking anyone to adopt a new pattern. See index.js for the full comparison in comments.

The engine

vendor/plantuml.js and vendor/viz-global.js are both committed in this repo, so there's nothing to build before loading the plugin. plantuml.js is generated by the main PlantUML project's own TeaVM build (gradlew.bat teavm from C:\github\plantuml, output produced at build/generated/teavm/js/plantuml.js) — it isn't auto-generated here, so if the engine changes upstream, re-run that build and copy the new plantuml.js from there over vendor/plantuml.js in this repo.

Loading it in Logseq (unpacked, for testing)

1. Logseq → Settings → Advanced → enable Developer mode.
2. Logseq → ⋯ (top-right) → Plugins → Load unpacked plugin → point it at this folder (logseq-plantuml-js-plugin/).
3. Open any page, type /PlantUML diagram (local, no server). It inserts a {{renderer ...}} block plus a child block with a sample diagram.
4. Edit the sample source, then click Render (local, offline).

Known rough edges (it's an MVP)

• Not yet verified against a live Logseq install. The macro-renderer / provideUI / provideModel wiring follows the exact pattern cofcool/logseq-plantuml-plugin's index.ts already uses in production (read directly from its source to build this), but this specific file hasn't been run inside Logseq yet — treat step "Loading it in Logseq" above as the actual first test.
• The engine's SVG output may include an XML prolog (<?xml version="1.0"...?>) before the <svg> tag. cofcool's plugin writes a bare <img src="..."> into the block; this plugin writes the raw SVG markup instead. If Logseq's block renderer chokes on the prolog or on inline <svg> specifically, stripping everything before the first <svg in index.js's success handler is the likely fix.
• @logseq/libs is loaded from cdn.jsdelivr.net in index.html (the same approach the official logseq-hello-world sample uses) — fine for an unpacked/dev plugin, but a real network dependency at plugin load time works against the "zero network" pitch. Vendoring it locally with a small esbuild bundling step is the natural next change before this goes further.
• No icon, no screenshot/gif, no manifest.json for the marketplace — see below.

What's left for an actual marketplace submission

Per logseq/marketplace's process, this plugin would need to:

1. Live in its own GitHub repo (not inside the plantuml monorepo) — done: this repo, with a tagged release that attaches a built .zip (still to do).
2. Have at least one screenshot or GIF and a clearer README.
3. Get a manifest.json entry added via a PR to a fork of logseq/marketplace — that file (title, description, author, repo) is separate from anything in this folder; it lives in the marketplace repo itself, pointing at plantuml/logseq-plantuml-js-plugin.

The more realistic path, though, is probably not a brand-new listing at all: opening this as a PR (or an issue with this code attached) against cofcool/logseq-plantuml-plugin directly, offering it as an additional backend next to the existing PlantUML-server option — same idea as the Obsidian and Outline proposals in this repo's docs/ folder.