The Library Is a Real Folder
There's no database and no virtual tree behind the Library. It is a folder tree on disk, at ~/Documents/eXLib Library (the resolved path is shown, with a Copy button, in Settings → Library). Everything the panel shows you is a direct read of that folder, and everything you do in the panel — move a row, rename a folder, delete an item — writes back to the same files a moment later.
The library is a real folder
Moving something in the UI moves the actual file(s) on disk. There's no separate index that can drift from what's actually there — the panel and the filesystem are two views of the same truth, and Settings → Library shows the resolved root path alongside live expression and folder counts.
These screenshots were captured in an earlier beta. Toolbar and Library layouts have since changed; the written instructions on this page describe v0.145.4. See A Tour of the Panel for the current controls.
What a library item is on disk
An expression is always a .js + .meta.json pair. A saved pseudo rig is always a .pseudo.json + .ffx pair. Each pair always moves together, whether you drag it in the panel or move the files yourself in Finder or a terminal.
The watcher — a genuine two-way view
A debounced filesystem watcher picks up external edits — renaming a pair, or editing an expression's code directly in Finder or VS Code — and reflects them live in the UI without a restart. It's a genuine two-way view: the app isn't just reading the folder once at launch and caching it.
Editing and authoring by hand
Because the library is just files, you can edit an expression's code directly in any editor, rearrange pairs in Finder, keep the whole tree in version control, or share it — all without the app in the loop, and the panel reflects it the moment the watcher notices.
A library item is its pair, so hand-creating a new expression means giving it both halves: the .js code file and its .meta.json sidecar. Duplicating an existing pair and editing both files is the quickest template — a bare .js with no sidecar isn't a library item yet.
Pseudo rigs are the exception: the .ffx half is a binary After Effects animation preset — not something you can write by hand — so a rig can't be authored from scratch on disk. Author it in Pseudo Effect Authoring, then move, version, and share the saved pair like any other files.
The order sidecar
Custom folder order — the arrangement you get from dragging folders into a non-alphabetical order, see Folders, Order & Batches — lives beside the folders in its own hand-editable sidecar, _meta/folder-order.json, namespaced across both roots: { schemaVersion, expressions, pseudo }. It's tolerant of stale entries on read, pruned on write, and reconciled through the same watcher that reflects every other external edit — so hand-editing the order file works exactly like hand-editing anything else in the library.
The library is the disk. There is no virtual tree standing in front of it — what you see in the panel is a live rendering of the folder, not a cached record of it.