obsidian-metadata
Typed access to the repo-root metadata.json — the per-Obsidian-app-version data table precomputed in this repo (installer-floor / recommended-installer / recommended-Electron thresholds; see the metadata.json section in CLAUDE.md). This is the single module that reads the raw table; everything else consumes it through getVersionMetadata against the ObsidianVersionMetadata shape, so the raw table stays internal and the public surface is a typed lookup.
The table is injected at build time by esbuild’s define (and at test time by Vitest’s define) — the OBSIDIAN_METADATA global is replaced with the parsed contents of metadata.json. This mirrors how OBSIDIAN_INTEGRATION_TESTING_VERSION is injected, and keeps the built library self-contained (the table is inlined into the output, with no runtime file read and no bundle-time JSON import that bundle: false cannot inline).
Interfaces
Section titled “Interfaces”| Interface | Description |
|---|---|
| ObsidianRuntimeVersions | The concrete JS runtime versions an installer’s Electron shell ships — the entire process.versions object, read empirically by booting that installer over CDP (see scripts/collect-runtime-versions.ts). Absent for versions not yet collected (or that could not be booted). These are the WINDOWS (.exe) values, and that matters. A given Electron version does bundle the same Node / V8 / Chromium everywhere — but the Electron version itself is a property of the installer, not of the release, and two installers of the same Obsidian version can differ: 1.12.4 shipped Electron 39.6.0 in its .exe and 39.7.0 in every other installer, and 1.8.10 shipped 34.2.0 vs 34.5.2. This field carries one flat value, measured on the .exe — the installer that, with the .dmg, is published for all 106 installer-bearing releases. So a consumer pinning a macOS or Linux installer should treat electron as accurate to the patch only for the 104 releases where the platforms agree. The collection workflow boots all three platforms and reports any new divergence. The index signature carries every key process.versions exposes for that Electron build — beyond the four well-known ones below, that typically includes ares, brotli, cldr, icu, llhttp, modules, napi, nghttp2, openssl, tz, unicode, uv, zlib (and, on newer Electron, ada, simdjson, …). The exact set varies by Electron version, which is why it is captured wholesale rather than as a fixed field list. |
| ObsidianVersionChangelogUrls | The changelog page URLs for a version, one per publication target, baked into metadata.json from Obsidian’s own changelog feed (obsidian.md/changelog.xml — see the metadata.json section in CLAUDE.md). Obsidian publishes a separate changelog page per platform (desktop / mobile) and per channel (public / catalyst “early access”), each at its own dated slug — the catalyst page typically predates the public one by about a day. Every key is optional: a version carries only the pages the feed actually published for it (a catalyst-only build has no desktop, a desktop-only release has no mobile, and the oldest versions predate the mobile app entirely). Caveat for the mobile keys: before 1.4.8 (2023-09-05) the mobile app ran its own version line, so a same-keyed mobile page documents a different release than the desktop page beside it (mobile 1.4.5 shipped 2023-05-23, desktop 1.4.5 2023-08-31). From 1.4.8 on the two lines track within days. |
| ObsidianVersionDownloads | The pre-resolved asset download URLs for a version, baked into metadata.json from the obsidianmd/obsidian-releases release assets — plus, for catalyst builds, the releases.obsidian.md CDN, which publishes no listing and so is probed (see the metadata.json section in CLAUDE.md). These are the exact URLs the version’s assets are published at, so the integration-time download paths can skip the GitHub release-API lookup and the historical dot-vs-hyphen asset-name guessing. Only the assets this library actually downloads are carried: the app asar, the x64 desktop installers, and the Android apk. A field is absent when the version publishes no such asset (e.g. a catalyst build ships only the asar), in which case the caller falls back to its hand-rolled resolution. |
| ObsidianVersionMetadata | The subset of a metadata.json per-version entry this library reads. Every field is optional — an entry carries only the thresholds that apply to that version (e.g. only old versions carry minRecommendedInstallerVersion). |
Functions
Section titled “Functions”| Function | Description |
|---|---|
| getVersionMetadata | Looks up the metadata entry for a concrete Obsidian app version. |