wiki-plugin-file

Read a file from a federated wiki page's assets folder, inside the page.

Farms serve assets with whatever Content-Type their mime table guesses, so browsers download .toml, .py, .rs and even .md. This plugin fetches the bytes with fetch() (which ignores Content-Type) and renders them itself: markdown through the wiki's own markdown plugin (wikilinks resolve), TOML as one table per section, JSON pretty-printed, code with line numbers, images inline. Every text file gets Raw (opens a text/plain blob in a new tab, which every browser displays), Download, Copy and the asset URL.

Item text

FILE BUGS.toml                     a file in this page's own assets folder
FILE assets/other-slug/notes.md    a file in another folder on this site
FILE https://host/assets/x/y.md    any absolute asset URL
FOLDER [slug | https://host/assets/path]   list a folder; click a name to read it
LINES 60                           collapse threshold (default 40)
SHOW                               start expanded

An empty item lists the page's own folder.

Provenance and drift

If the folder carries a SOURCES.toml manifest (written by asset-snapshot.py), the viewer shows each file's role, source path, repo, commit and snapshot date, and hashes the fetched bytes: a green badge means the file still matches the manifest, red means it was edited in place or the manifest is stale.

Lazy loading

The client ships as two files: client/file.js (~14 KB, always loaded) and client/toml.js (~11 KB, the smol-toml parser), which the main bundle fetches from /plugins/file/toml.js the first time a .toml file is rendered as tables. SOURCES.toml provenance uses a built-in mini reader (flat tables of strings, numbers, booleans), so folder lists, badges and non-TOML files never trigger the extra request. If toml.js cannot load, the file is shown raw with a note.

Build

npm install
npm run build     # esbuild → client/file.js
npm test