Logseq Publish SPA

Why it's ranked here

This is a focused bridge between Logseq’s own parser, publishing code, and automated hosting workflows. It validates required directories, pins or accepts a chosen frontend revision, and tests the action against a sample graph. The narrow file-graph scope is the main qualification.

What's good

The action accepts graph and output locations, a specific Logseq tag or commit, theme mode, and accent color. Build caching reduces repeated frontend and dependency work. Invalid theme choices fall back to light, invalid accent colors fall back to blue, and publishing errors stop the process.

Tradeoffs

Database-backed graphs are unsupported, with preliminary support placed on indefinite hold. Local use requires Babashka, Clojure, Node package installation, a separate Logseq checkout, and a one-time frontend build. Opening exported files directly can break assets and slides, so local inspection needs an HTTP server.

How to use it well

Choose it for a file-based Logseq graph already kept in Git and published after pushes, especially through GitHub Pages. Pin the action and Logseq frontend revisions when stability matters, then configure Logseq’s publication rules carefully. It does not cover database-backed graphs or replace the separate deployment step.

Observed

License

ISC declared in package metadata; LICENSE.md provides a permissive grant with warranty disclaimer.

Primary implementation language

ClojureScript, loaded and executed through NBB from a small JavaScript entry point.

Install surface

npm or Yarn global installation exposes a command-line binary.

Interfaces

Composite GitHub Action and local CLI.

Graph support

File-based Logseq graphs only; database-backed graphs are not supported.

Automation platform

GitHub Actions workflow designed for Ubuntu runners, with a documented GitHub Pages deployment workflow.

Verification structure

Separate CI lint workflow and pull-request workflow that runs the action on a test graph.