The bundler-independent half of building an Obsidian plugin: which modules stay external, where the output goes, what the output folder holds besides the bundle, and how a development build reaches the vault. Every bundler adapter in this folder (esbuild, rollup, vite, webpack, parcel) is a thin layer over it, so all of them produce the same main.js + styles.css + manifest.json layout.
| Function |
Description |
| cleanObsidianPluginDistFolder |
Removes the output folder of a build and creates it empty again. |
| completeObsidianPluginDistFolder |
Puts the files a plugin folder needs besides the bundle into the output folder: manifest.json, and for a development build reloaded by the HotReload plugin the empty .hotreload marker it watches for. |
| getObsidianPluginBanner |
Builds the banner placed at the top of main.js. |
| getObsidianPluginDistFolder |
Resolves the default output folder of a build: dist/build for a production build, dist/dev for a development one. |
| getObsidianPluginEntryPoint |
Resolves the plugin’s entry point, src/main.ts. |
| isCssFileName |
Tells whether a file name is a CSS file. |
| isObsidianPluginExternal |
Tells whether a module id is one an Obsidian plugin bundle must leave external: one of OBSIDIAN_PLUGIN_EXTERNALS, a subpath of one (@codemirror/view/dist/index.js, fs/promises), or any node:-prefixed id. |
| mergeCssAssets |
Decides how the CSS a bundler emitted becomes the one styles.css Obsidian loads. Obsidian reads a plugin’s stylesheet from styles.css and nothing else, while a bundler names the CSS after the entry (main.css), after the package, or with a content hash. A lone CSS file is renamed; when there are several, they are concatenated in the order given. |
| resolveFromRoot |
Resolves a path against the project root. |
| resolveObsidianPluginBuildContext |
Resolves where a plugin build writes its output, which entry point it builds and which vault a development build is deployed into. Loads the project’s .env file first, so OBSIDIAN_CONFIG_FOLDER can live there. |
| Type |
Description |
| ObsidianPluginReload |
How a development build is reloaded in Obsidian once it is copied into the vault. - 'hot-reload-plugin': the build writes the .hotreload marker, and npm run dev opens the vault in an Obsidian instance it owns, with the HotReload plugin installed and enabled there. - 'obsidian-cli': every rebuild runs obsidian plugin:reload against the Obsidian you already have open, through the Obsidian CLI (Settings → General → Command line interface). No HotReload, no second instance. - false: the build is copied into the vault and nothing reloads it. |
| Enum |
Description |
| BuildMode |
Enumeration representing the build modes. |
| Variable |
Description |
| OBSIDIAN_PLUGIN_EXTERNALS |
The module ids an Obsidian plugin bundle leaves to require() at runtime: the OBSIDIAN_PLUGIN_RUNTIME_MODULES and the Node builtins. Every node:-prefixed id is external too, which a bundler takes as a pattern (esbuild’s node:*) or through isObsidianPluginExternal. |
| OBSIDIAN_PLUGIN_RUNTIME_MODULES |
The modules Obsidian supplies at runtime. A plugin must never bundle its own copy of them: a second copy of the API breaks instanceof against the running one, and a second CodeMirror breaks every extension. esbuild and eslint are here because a plugin that imports one of the toolkit’s build-time modules would otherwise drag either into main.js. |