Summary
use separate npm distribution tags for the public and Catalyst versions of the official obsidian API package
For example:
obsidian@latest → API declarations for the newest public Obsidian release
obsidian@catalyst → API declarations for the newest Catalyst/early-access release
This would make the application release channel explicit to plugin developers and dependency-update tools while preserving exact version installs.
Current behavior
The official obsidian npm package currently has a latest tag, but no separate public or Catalyst channel tag.
During the Obsidian 1.13 release cycle:
[email protected]was published and became npm’slatestversion on June 9, 2026.- Obsidian 1.13 remained available only through Catalyst until Obsidian 1.13.4 was released publicly on July 30, 2026.
- The official sample plugin depends on
"obsidian": "latest", and its README recommends runningnpm updateto receive API updates.
For roughly seven weeks, following the default npm and sample-plugin workflow therefore selected API declarations associated with an early-access application line.
Compiling against newer declarations does not automatically raise a plugin’s runtime requirement: obsidian is normally a development dependency and is externalized from the plugin bundle. However, newer declarations can make APIs available to the compiler that are absent from the plugin’s declared minAppVersion. That compatibility difference must then be noticed, guarded, and tested by each plugin author.
Why a separate channel would help
npm install obsidianwould continue to mean the newest API available to all Obsidian users.- Developers intentionally testing Catalyst APIs could opt in with
npm install --save-dev obsidian@catalyst. - Dependabot and similar tools would not move a stable-targeting plugin onto early-access declarations as an ordinary update.
- A plugin’s compile-time API target and
minAppVersionwould be easier to reason about. - Exact version pins would continue to work exactly as they do today.
npm supports this without republishing package versions. Early-access declarations could be published or tagged as catalyst, and the existing version could be promoted to latest when that Obsidian line becomes public:
npm publish --tag catalyst
# Later, when the corresponding Obsidian line becomes public:
npm dist-tag add obsidian@<version> latest
If catalyst is considered too product-specific for npm, next or beta could serve the same purpose.
Related discussion and precedent
obsidian-typingsissue #123 discussed the difficulty of mixing public and Catalyst internal API declarations.obsidian-typingsissue #124 implemented separate public and Catalyst release/package channels. During the 1.13.4 promotion, its Catalyst package was available first and itspublic-latestpackage was updated after the public Obsidian release.- An Obsidian forum report documents a runtime failure caused by compiling against an
obsidianAPI package newer than the installed Obsidian runtime. - Other requests have raised related version-traceability concerns between the npm package and GitHub and between npm versions and repository tags.