Publish only plugin architecture

[bitbonsai]

TLDR; Plugin support for Typora, but for one function only: Publish to...

What

A plugin architecture that allows developers to extends Typora publishing capability. Some possible examples:

• Save as Draft onMedium.com
• Save to Dropbox Paper
• Create Gist on Github
• Create Snippet on BitBucket
• Commit and push to Master of yourblog.com
• Save as Draft to some-fancy-headless-cms
• Trigger some facy web hook
• A multitude of places/custom blogs/engines I can't even think of

Why

Publish to... is a feature that takes typora to the next level, insteaf of being an editor could be a platform to edit content on the web with direct integration.

But to think about all possible integrations or keep adding them might add clutter to the app, taking out the KISS approach, or take out the @typora's team focus on what's more pressing.

Creating a publish plugin architecture makes possible to:

1. Keep Typora simple, only having 2 or 3 default exporters
2. Share development effort with a big developer community that could create custom publish plugins
3. Design agency to create a plugin for a specific client, and recommending them to use Typora as the CMS editor

How

Similarly on how Typora handles plugins right now.

A plugin folder, that has all publish plugins available.

The 2 or 3 default ones serve as boilerplates, documentation is on how the default ones were created, and the community provides support to itself.

One page on typora.io where authors can submit plugins, linked to a public git repo. Stars, comments, issues, can be dealt with by each plugin author on GitHub or equivalents.

Private plugins can be created and used, with no need to register on typora.io

What does success looks like?

• ↑ On publish plugins creation
• ↑ Installation of plugins
• ↓ Support or Issues related to publish

[bitbonsai]

Possible workflow

A plugin folder where I could download the plugin, a json containing

name of plugin	string [unique]
description of plugin	string
prompt	string (opens a system dialog with configuration prompts, like tokens or username:passwords)
command	string (can be a system command, to allow git workflows)
log	boolean (opens a dialog to show progress during publication)
afterComplete	string [url] (opens page with the published content)

[youmengme]

This is a good idea, and I support it.