writer-computer: a local-first desktop Markdown workspace

Why writer-computer keeps Markdown in the workspace

writer-computer addresses a straightforward desktop-editing problem: how to edit Markdown documents without moving them into a separate notes database or cloud workspace. The README describes the application as an app for workspace Markdown files and states that documents stay on disk. The surrounding project directory is therefore the organizing boundary, rather than an account, remote workspace, or proprietary document collection.

The repository is aimed at people who already organize work in folders and repositories. Developers may use it for README files, specifications, documentation, and project notes, while writers may keep manuscripts or notes in Markdown. The repository contains `SPECs/` and `docs/`, which fits that model. However, the README does not document audience-specific workflows for either group, so this is an inference from the file-oriented design rather than a stated product promise.

Workspace integration is more specific than simply calling the application local-first. The README says that Writer respects workspace `.gitignore` rules. Workspace-aware discovery can therefore use the project's ignore configuration instead of treating every local file as an editable document. The README does not explain whether this affects opening, watching, searching, indexing, or all related operations, so the exact scope of the behavior should be confirmed before selecting the editor for a repository with complex ignore rules.

Tauri, Rust, React, CodeMirror, and Zustand shape the desktop architecture

The documented stack places a Rust and Tauri v2 backend behind a React frontend. CodeMirror supplies the editor foundation, while Zustand is listed as part of the frontend state layer. The repository layout makes the separation visible: React files live under `apps/desktop/src/`, and Rust commands, workspace state, the watcher, updater code, and CLI integration live under `apps/desktop/src-tauri/src/`.

This arrangement indicates a local desktop application with a frontend for interaction and a native side for filesystem-related work. Workspace state, file watching, and CLI integration are specifically assigned to the Rust area, which is consistent with a design that needs to react to local file changes and coordinate with a workspace. The README does not provide command signatures, IPC boundaries, or watcher debounce settings, so those implementation details cannot be described beyond the components named in the repository documentation.

The application also supports multiple windows. The README names that capability but does not explain window lifecycle, workspace selection per window, or whether windows can edit the same file concurrently. Those omissions matter for an editor because multi-window support can either separate documents conveniently or make shared state and file watches harder to reason about. The available evidence establishes the feature, not its exact behavior.

Extended Markdown rendering beyond plain text editing

writer-computer is not limited to a plain-text editing surface in its stated feature set. The README says that it renders extended Markdown, including tables and Mermaid diagrams. CodeMirror provides the editing environment, while the rendering path is described as part of the desktop application. For technical writers, tables and diagrams are useful when the source document needs to remain portable Markdown while still being readable during editing.

The README does not identify a separate preview mode, keyboard shortcut, export command, or configuration option for Mermaid. It also does not state whether editing rendered diagrams is supported. As a result, the safe interpretation is that Writer can render those constructs, not that it provides a visual diagram editor or a documented round-trip editing workflow. A team considering it for design documents should verify that the exact Markdown syntax used in its files is accepted and that the application does not rewrite the underlying file unexpectedly.

Keeping files on disk is also significant for review and version control. A Markdown document can remain inspectable with the tools already used around the workspace. The README does not promise Git commits, branch switching, conflict resolution, or synchronization with remote repositories, so writer-computer should not be treated as a Git client on the evidence available.

Running writer-computer from the repository

The README gives a development setup rather than a packaged installation procedure. It states that the repository uses Vite+ through the `vp` CLI and explicitly instructs contributors to use `vp` instead of calling the package manager or Vite tooling directly. The top-level `package.json` declares Node.js `>=22.12.0`, pnpm `10.32.1`, and a private package named `writer-computer`.

For a first developer use, install the declared toolchain, then install the repository dependencies. These commands are documented exactly as follows:

vp install
vp dev

`vp install` prepares the project dependencies through the required Vite+ workflow. `vp dev` starts the development workflow for the desktop application. The README does not document a separate first-run UI sequence, so after the development command starts, the reader should follow the application window and workspace prompts that appear rather than expecting a documented setup wizard or sample document.

The top-level script identifies the desktop development entry as `desktop#dev`, but the README tells users to run `vp dev`, so that higher-level command is the appropriate documented first action. The README does not provide binaries for Linux, Windows, or macOS, and it only documents a signed macOS release flow. There is therefore no supported user-facing installation command to reproduce from the README.

Validation for contributors and desktop changes

The repository provides separate checks for the JavaScript and Rust portions of the project. The README lists the top-level validation commands:

vp check
vp test

These are the documented commands for repository-wide checks and tests through Vite+. The `ready` script in `package.json` gives a more specific validation sequence, including formatting, linting, tests, and builds:

vp fmt && vp lint && vp run test -r && vp run build -r

That script is a package-level command definition, while the README presents `vp check` and `vp test` as the normal validation entry points. The Rust crate has its own documented commands:

cd apps/desktop/src-tauri
cargo test
cargo clippy
cargo fmt --check

Running these from the Tauri crate checks Rust tests, lint rules, and formatting. The separation is practical because the application includes both a React frontend and a Rust desktop backend. The README does not state operating-system requirements for development, supported screen readers, or a CI status, so those points cannot be treated as confirmed capabilities.

For a contributor changing watcher or updater code, the Rust commands are especially relevant because the README places workspace state, watching, updater logic, and CLI integration in `apps/desktop/src-tauri/src/`. No claims about current test coverage or passing status can be made from the repository listing alone.

Privacy, releases, and maintenance boundaries

The privacy model is explicit for a small repository. The README says usage telemetry is opt-in, off until enabled, does not see documents, file names, or paths, and is not compiled into builds made from a clone of the repository. It points to `docs/telemetry.md` for the event and property list and describes three independent ways to keep telemetry off. That makes the default privacy posture clear, although the README excerpt does not reproduce those three settings or mechanisms.

Release handling is documented mainly for macOS. The README says macOS releases are cut locally with `scripts/distribute.sh`, and points to `docs/releasing.md` for signing, notarization, and updater publishing. The repository contains release documentation and updater-related Rust code, but the README does not specify release artifacts, automatic update behavior, or platforms other than macOS.

The repository is not archived, and its last push was on 2026-10-05. Recent releases listed for Writer are `v0.7.3` on 2026-10-05, `v0.7.2` on 2026-09-22, and `v0.7.1` on 2026-09-21. This supports a recent development record, but it does not establish a long-term support policy or compatibility guarantee. License information identifies the project as GPL-3.0. Distribution and modification should be reviewed against that license and the project's release files; the README does not provide legal interpretation.

Editorial conclusion

writer-computer fits developers and writers who want a desktop editor that works directly with Markdown files in a workspace and accept building or running it through the documented development workflow. It is a weaker choice for users who need packaged downloads, platform coverage beyond the documented macOS release flow, or detailed first-run instructions. Before adoption, verify the intended platform, the editing and export behavior against the project's specifications, and the telemetry and updater settings relevant to your deployment.

Frequently asked questions

Official sources

1. Issues
2. joelbqz/writer-computer on GitHub
3. License: GPL-3.0
4. README
5. Releases