How to get started with developing a custom Plugin?

Like the title says, I would like to know how to get started with developing a plugin on my own. It would be great if people who have made a plugin, share their workflows so that newbies like me can walk in their footsteps :slight_smile:

13 Likes

Interested as well!

2 Likes

FAQ

Docs

2 Likes

I added a small section about this at the bottom:

11 Likes

+1 for sharing the workflow, especially what happens after npm run dev:

  • Do you manually copy over your files to VaultFolder/.obsidian/plugins/your-plugin-id/ when you’ve made a change?
  • Do you re-load your local Obsidian to see changes?
    etc.
5 Likes

I don’t think Typescript knowledge (or use) is really necessary to write Obsidian plugins. You can just write plain Javascript using ES2018 features (such as classes, generators, and async functions), which are available in most browsers as well as Electron.

If you code directly in JS and CSS in a subdirectory of your plugins folder, you don’t need node, npm, rollup, typescript, or really any of that stuff. The main difference from the example code is that instead of writing import {...whatever} from "obsidian"; you write {...whatever} = require("obsidian");, and leave out any type declarations/casts. That’s pretty much it.

Of course, while doing development, you may need to reload your plugin after making changes. You can do this by reloading, sure, but it’s easier to just go to settings and then toggle the plugin off, then back on again

You can also automate this process from within the plugin itself, by including a command that does something like this:

const id = this.manifest.id, plugins = this.app.plugins;
plugins.disablePlugin(id).then(() => plugins.enablePlugin(id));

This will reload the plugin from disk and run the new version’s onload(), after first calling the old version’s onunload(). It’s basically the same as going into the settings and toggling the plugin off and back on again.

The main downside to not using Typescript and rollup is that you can’t use any node modules in your plugin without copying and pasting. For the plugins I’ve been developing so far, this is not really an obstacle, though.

I am somewhat curious as to why the Obsidian devs are using an ES5 target in the sample plugin, though, as it means that many Typescript features will be emulated in Javascript rather than using the V8 native versions: notably classes and async functions are emulated when using an ES5 target.

(It’s possible that Obsidian itself is being built with such emulation in order to enable Typescript features that don’t work with ES2015+, such as decorators. But ISTM that wouldn’t be a reason for plugins to do that sort of emulation, too.)

7 Likes

this response is so helpful. thanks a lot

  • @zephraph put together some tools for programmatically working with plugins. There’s also an unofficial collection of CLI tools that helps you build plugins for Obsidian. Apparently it’ll prompt you for which vault you want to develop in (via a select list; it finds all your vaults), sets up and automatically copies over built code, and prompts to you to install the hot-reload plugin if you haven’t already (it’ll do that for you automatically too). It’ll even copy over the manifest file if any changes happen to that.
3 Likes
4 Likes