Plugin/theme collections, and plugin dependencies/incompatibilities

Use case or problem

The plugin landscape is exploding and that’s great! But at the same time, when the library gets too large, that’s when finding things becomes difficult and efforts get duplicated.

I think this is well known. The Roadmap was updated recently to indicate a plugin browser is next priority. But one of the most powerful ways to make things easy to find is to reduce choices. And you can easily choices by grouping plugins together.

For my own use case, I want to turn Obsidian into a developer focused note taking tool. There are many plugins that do this - dataview/core, codescript toolkit, inline scripts, etc. etc. But knowing which ones work well together and which don’t is difficult. If I put in the work to make a pack of well known plugins that work together, theres no straightforward way to communicate to other people what the exact set of plugins should be to get the same experience as me. I believe shared experiences build community and community attracts strength in a positive feedback loop. So a unified experience targeted towards one specific group of people will have a greater positive impact than a fragmented experience.

A recent example of this? Notebook navigator. Personally, I’ve tried it and do not use it for my main vault. But it’s hard to deny it’s meteoric rise in popularity on the reddit community. A common thread in the comments on the first few iterations of NN was “Finally I can drop x plugin and y plugin too”. Maintaining a list of many small plugins is a lot of cognitive load for non-developers. And when that list gets long, people burn out on plugins and abandon for “simpler things” or software that aligns closer to their use case out of the box.

As a developer, this could also make plugins play nicer with each other overall. Take for example this feature request for a type system in Obsidian. It resulted in a powerful mdbase spec proposal from Callumpass - which they have used to augment their popular plugin TaskNotes. Other plugins wanting to build off that foundation could attempt to implement the spec for themselves. But if dependencies existed, then a utility plugin that provides an api for working with mdbase could cut down on plugin development time.

It also gives visibility to you as the obsidian devs as to what features could use native obsidian treatment - shared dependencies get lots of downloads because the downloads from all plugins that use them are counted towards the dependency. But with manual integration, it’s not easy to tell that a feature is universally implemented in many separate plugins.

Proposed solution

I think the greatest plugin experience I’ve ever encountered is the mod portal for factorio: https://mods.factorio.com/

Mods can list both dependencies, and incompatible mods. The portal can be browsed both via website, and in software. When selecting a mod you want, it also selects required dependent mods. It also easily lists other mods you may wish to select as well. If a required dependency is missing it warns you immediately. It also tracks if YOU downloaded a mod or if the mod was just downloaded because it was needed by a plugin you wanted.

There is also a category just for “modpacks” or mods that are nothing more than a group of other mods. You cannot believe how great it is to just download a “quality of life” mod pack that totally hits all the things you wanted, or gives you the same experience you saw someone else have in one click.

This also has plugin review benefits. As it stands, to make a unified plugin like NN, you would need to manually incorporate all plugins into each other, then submit the new plugin for review. It would certainly become a large plugin due to the things it incorporates. With plugin/theme packs, a plugin could be simply a list of other plugins to get, and potentially some minor alterations to make them work better together. That’s much less code to review (though of course not zero! I’m not suggesting that would make plugin review cheap, only that in many cases a security review of a plugin pack could be less effort than one of a massive overhaul plugin that combines them manually).

Current workaround (optional)

Currently the community has a few ways to workaround this

  • Plugin authors are manually mentioning which plugins can enhance the experience if downloaded at the same time. See for example notebook navigator - which advertises better search if you also download omnisearch
  • Community influencers are releasing videos that explain good groups of plugins that community members must download and configure themselves. A quick search for plugins almost always brings up these kinds of videos.
  • Community members also release vaults with everything pre-downloaded and configured. Which is nice, but only if you are starting a new plugin, and only if you trust a vault download from a third party which could actually contain anything.

Related feature requests (optional)

  • There is a stub of a feature request related to this buried in the developer api forum. But the idea I’m proposing is legitimately non-developer user facing, so I do not consider it a duplicate

  • A search for “dependency” only brought up javascript dependency posts

2 Likes

Another workaround would be to post in Share & showcase.