You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While it's still early days for plugins in Noteplan, it might make sense to keep all the "blessed" plugins in this Github repo, but longer term, that'll start to get untenable. Specially when it comes to releases.
Using a package manager like NPM might make a lot of sense. Using registry.npm.org URLs it's fairly straightforward to search, get details and download packages that can go directly to the Plugins folder.
Here are the benefits to this approach:
Third party packages can all follow a naming convention (e.g. noteplan-plugin-commandName) and publish them on NPM and they will become easily discoverable for users.
NPM packages have versioning built-in and it will become easy for different plug-ins to be updated independently and for Noteplan to periodically check for updates easily by package name.
Since NPM allows for an independent .npmignore file it'll become easy to ignore built files for GitHub and ignore source files for the NPM package. This way Noteplan doesn't have to download any unnecessary files.
It should still be valid to use a Github URL to manually download plugins that aren't on NPM. (without all the extra feature though)
Possible downsides:
Churn - NPM can be an additive feature so that the churn can be kept to a minimum.
it slightly increases the barrier to entry, but it's really just an npm publish command for a plug-in author. For advanced plugins this would be a total win.
it slightly increases the barrier to entry, but it's really just an npm publish command for a plug-in author. For advanced plugins this would be a total win.
This one can be solved by having a template repo that users can clone to start developing their plugins, kinda like how themes can be copied and edited now but a bit more complex. It should be easy enough to write a generator as well so all users would need to do is run npm init noteplan-plugin my-plugin to generate a my-plugin folder with all the relevant template files in it.
I've been playing around with this and I'm making gradual progress. I'm hoping to start by creating a NPM workspace called @NotePlan and putting the "first-party" plugins under that. We can take it from there. I'm gonna be busy with work for a couple of weeks though so I'll have some updates after that.
Do we really need npm for this? Seems like you could use the Github API directly -- tag repos with a particular topic, and then use the repo search endpoint to find repos tagged with the noteplan-plugin (or whatever) topic.
Using npm implies (to me) some need to also solve for various versions of dependencies. I hope NotePlan plugins do not need that.
I know the main VSCode way, as I maintain one of the extensions in the marketplace. That is a central repository, but anyone can get an account to add to it, without any possibility of trampling on (or using) other's extensions. There's no quality control, though you can rate and comment on extensions.
The BitBar / XBar / SwiftBar way is to have a central GitHub repo, and plugin authors submit PRs, which a few moderators add. This is effectively the main NP way at the moment.
Like the other VSCode way, NP already allows for other plugins to be added from any source a user decides to use. Reasonably enough there won't be a central list of these.
So, I wonder if the main thing to do in the shorter term is to add a button to the Plugins Preferences pane to 'Add Plugin ...' which would accept .gzip archives and unpack them into the user's folder, in the same way as for official plugins. This makes it a simple-enough step for non-techies to add from any source they wish.
Activity
leomeloxp commentedon Jun 7, 2021
This one can be solved by having a template repo that users can clone to start developing their plugins, kinda like how themes can be copied and edited now but a bit more complex. It should be easy enough to write a generator as well so all users would need to do is run
npm init noteplan-plugin my-pluginto generate amy-pluginfolder with all the relevant template files in it.nmn commentedon Jun 11, 2021
I've been playing around with this and I'm making gradual progress. I'm hoping to start by creating a NPM workspace called @NotePlan and putting the "first-party" plugins under that. We can take it from there. I'm gonna be busy with work for a couple of weeks though so I'll have some updates after that.
jgclark commentedon Jun 11, 2021
cweagans commentedon Jun 17, 2021
Do we really need npm for this? Seems like you could use the Github API directly -- tag repos with a particular topic, and then use the repo search endpoint to find repos tagged with the
noteplan-plugin(or whatever) topic.Using npm implies (to me) some need to also solve for various versions of dependencies. I hope NotePlan plugins do not need that.
dwertheimer commentedon Jul 10, 2021
Agree that having only one way to get NP plugins out to the world is limiting.
Obsidian's way of dealing with this seems to work -- they have "safe" (blessed) plugins and "community" plugins:
https://help.obsidian.md/Advanced+topics/Third-party+plugins
Then to get listed in the community directory:
https://github.com/obsidianmd/obsidian-releases
...or do it the VSCode way:
https://code.visualstudio.com/api/working-with-extensions/publishing-extension
jgclark commentedon Jul 10, 2021
I know the main VSCode way, as I maintain one of the extensions in the marketplace. That is a central repository, but anyone can get an account to add to it, without any possibility of trampling on (or using) other's extensions. There's no quality control, though you can rate and comment on extensions.
The BitBar / XBar / SwiftBar way is to have a central GitHub repo, and plugin authors submit PRs, which a few moderators add. This is effectively the main NP way at the moment.
Like the other VSCode way, NP already allows for other plugins to be added from any source a user decides to use. Reasonably enough there won't be a central list of these.
So, I wonder if the main thing to do in the shorter term is to add a button to the Plugins Preferences pane to 'Add Plugin ...' which would accept .gzip archives and unpack them into the user's folder, in the same way as for official plugins. This makes it a simple-enough step for non-techies to add from any source they wish.
nmn commentedon Jun 28, 2022
Benefits of NPM
.gitignoreand.npmignorefiles.noteplan-plugintag on NPM, we can make all third-party plugins easily accessible on NPM.Downsides of NPM
jgclark commentedon Oct 12, 2026
This was never properly picked up, and the deliver-through-GitHub has been firmly established and developed for 5 years. So closing this idea.