Skip to content

obsidian/demo-vault-naming

The names a plugin’s demo-vault release artifact carries — the one contract between the release-time packaging step and the runtime opener.

The two live far apart: script-utils/demo-vault.ts runs under Node at release time and WRITES the archive, while desktop-demo-vault-opener.ts runs inside Obsidian and DOWNLOADS it by name. They used to agree by a comment on each side saying the other must be changed too, which is exactly the sort of pairing that survives until the day it does not. Both now derive every shared name from here.

Kept free of obsidian and node: imports on purpose: the packaging step runs under Node, where the obsidian module does not exist, and the opener sits in the generated barrels, which must stay safe to evaluate on mobile.

InterfaceDescription
GetDemoVaultFolderNameParamsParameters for getDemoVaultFolderName.
FunctionDescription
getDemoVaultArchiveFileNameThe file name of the demo-vault archive attached to a plugin’s GitHub release. Carries the plugin id so several plugins’ demo vaults never collide, and deliberately NOT the version: a release asset is already namespaced by its release tag (…/releases/download/<version>/…), so the version bought no disambiguation while making the asset name change on every release — which is what broke the Community directory’s finding overrides, whose fingerprint includes the name. The version lives inside the archive instead, as getDemoVaultFolderName and on the README’s heading.
getDemoVaultFolderNameThe name of the demo vault’s own folder — the archive’s single top-level entry, and the folder the opener extracts it to. One name serves both because they are the same folder seen twice: a user who unzips the archive by hand gets a self-describing, version-distinct folder rather than an anonymous one, and a user who runs the Open demo vault command sees that same name in Obsidian’s vault switcher.