From PHP to TypeScript: Rebuilding Wiki|Docs

Why I rewrote it?

Wiki|Docs started as a PHP project: a small, databaseless wiki built around a simple idea: your knowledge should live in files you can keep, move, and understand without depending on a database. That idea is still the heart of the project, but the original implementation had reached the point where evolving it across web and desktop experiences was becoming harder than it needed to be.

I wanted a codebase with stronger type safety, clearer boundaries, and a better day-to-day developer experience. Just as importantly, I wanted one language for the entire product instead of maintaining separate technological worlds for the frontend, backend, and desktop application.

Keeping the part that mattered

This was a rewrite of the application, not a change in philosophy. Wiki|Docs remains a flat-file wiki: configuration and metadata are JSON, pages are Markdown files with YAML frontmatter, and attachments are regular files on disk. No database is required.

That model keeps the data portable and makes self-hosting straightforward. Whether Wiki|Docs runs in a container, on a server, or on a desktop machine, the dataset remains a directory rather than an opaque service dependency.

One stack, three surfaces

The new version is written in TypeScript end to end. The shared language made it possible to define contracts once and use the same vocabulary across every layer, while still giving each part of the application a focused responsibility.

The Angular frontend is where that model becomes practical day to day: a focused workspace for navigating a wiki, opening documents, and keeping frequently used pages close at hand. It presents the file-backed knowledge base as an application without hiding its simple structure.

Behind that interface, the NestJS API makes the application boundary explicit. Its documented endpoints cover the health and lifecycle of the service as well as authentication, settings, accounts, and document operations, so clients can rely on a visible contract rather than implementation details.

Shared TypeScript contracts sit between these layers. This reduces duplicated assumptions and makes a change to an API payload visible wherever it matters.

Desktop and remote sync

The desktop application is fully standalone: it packages the frontend, launches the backend locally, and works entirely with a local dataset. A self-hosted remote instance is optional. When configured, the app compares the active document tree in the local dataset with that instance, then coordinates the exchange of changed documents. The backend stays focused on serving and applying changes; Electron owns the synchronization flow.

On the desktop, the same editor is packaged with the application so a new Markdown document can be created and managed locally, even without a remote connection. Native actions sit alongside the familiar writing workspace, keeping the experience close to the web client while giving Electron control of local files and optional synchronization.

The scope is intentionally narrow: document content and attachments travel between locations, while settings, accounts, pinned documents, and trash remain local to their respective datasets.