Closed nikku closed 2 years ago
The easiest thing would be to have a plugins.json
at the root of this project that provides this metadata. Other projects provide this via yml, which could be interesting as well.
I will research this thing a bit.
VS Code Marketplace
Electron Apps https://github.com/electron/apps/blob/master/apps/camunda-modeler/camunda-modeler.yml
name: 'Camunda Modeler'
description:
'Developer-friendly app for editing and executing BPMN process diagrams and
DMN decisions.'
website: 'https://camunda.com/products/modeler/'
category: 'Developer Tools'
repository: 'https://github.com/camunda/camunda-modeler/'
keywords:
- bpmn
- dmn
- modeling
- modeler
- diagram
- 'business process'
license: MIT
screenshots:
- imageUrl: 'https://raw.githubusercontent.com/camunda/camunda-modeler/master/docs/screenshot.png'
caption: 'BPMN Editor with properties panel'
imageLink: 'https://github.com/camunda/camunda-modeler'
JSON Schema Catalog https://github.com/SchemaStore/schemastore/blob/master/src/api/json/catalog.json
{
"$schema": "https://json.schemastore.org/schema-catalog.json",
"version": 1.0,
"schemas": [
{
"name": "AnyWork Automation Configuration",
"description": "AnyWork Automation Configuration used to configure automation scripts on AnyWork",
"fileMatch": [
".awc.yaml",
".awc.yml",
".awc.json",
".awc.jsonc",
".awc"
],
"url": "https://json.schemastore.org/anywork-ac-1.1.json",
"versions": {
"1.0": "https://json.schemastore.org/anywork-ac-1.0.json"
}
},
...
]
}
Fig Plugins https://github.com/withfig/plugins/blob/main/CONTRIBUTING.md#add-metadata-to-your-plugin
const plugin: Fig.Plugin = {
icon: "🔗",
name: "dropbox_zpm-zsh",
displayName: "Dropbox (ZPM)",
type: "shell",
description: "Zsh dropbox plugin",
authors: [
{
name: "zpm-zsh",
github: "zpm-zsh",
},
],
github: "zpm-zsh/dropbox",
license: ["GPL-3.0"],
site: "https://github.com/horosgrisa/zsh-dropbox",
shells: ["zsh"],
categories: ["Completion"],
keywords: ["zsh", "dropbox-plugin", "dropbox"],
installation: {
origin: "github",
sourceFiles: ["dropbox.plugin.zsh"],
},
};
export default plugin;
Obsidians Community Plugins https://github.com/obsidianmd/obsidian-releases/blob/master/community-plugins.json
[
{
"id": "nldates-obsidian",
"name": "Natural Language Dates",
"author": "Argentina Ortega Sainz",
"description": "Create date-links based on natural language",
"repo": "argenos/nldates-obsidian"
},
{
"id": "hotkeysplus-obsidian",
"name": "Hotkeys++",
"author": "Argentina Ortega Sainz",
"description": "Additional hotkeys to do common things in Obsidian",
"repo": "argenos/hotkeysplus-obsidian"
},
...
]
What I could vision as a first step:
{
"version": "1.0.0",
"plugins": [
{
"id": "camunda-modeler-plugin-resize-tasks",
"displayName": "Camunda Modeler Plugin: Resize Tasks",
"version": "0.1.0",
"description": "Camunda Modeler Plugin That Makes Tasks Resizable",
"url": "https://github.com/philippfromme/camunda-modeler-plugin-resize-tasks",
"category": "BPMN"
}
]
}
Having this as a start, we can easily build things like compatibility
or installation
on top
{
"id": "camunda-modeler-token-simulation-plugin",
"displayName": "Token Simulation for the Camunda Modeler",
"version": "0.16.0",
"description": "Token simulation as a plugin for the Camunda Modeler",
"url": "https://github.com/camunda/camunda-modeler-token-simulation-plugin",
"category": "BPMN",
"compatibility": [
{
"plugin": {
"start": "8.0.0",
"end": "0.15.0"
},
"desktop-modeler": {
"start": "2.2.0",
"end": "4.12.0"
}
},
{
"plugin": {
"start": "0.16.0"
},
"desktop-modeler": {
"start": "5.0.0"
}
}
]
}
Obviously, a JSON Schema would be imaginable, also to verify the plugins.json
via CI. But that's optional (can be added later).
{
"$schema": "https://foo.bar.com/plugins-schema.json",
"version": "1.0.0",
"plugins": []
}
This would already enable us to make plugins discoverable
Looks promising. One possible improvement I could see is to have separate files for each of the plugins (cf. Electron apps or Homebrew formulae). This way, when I as a plugin maintainer add my plugin, it does not conflict with other pending contributions. I believe this could happen when everybody starts to modify the same array in a single JSON.
Looks promising. One possible improvement I could see is to have separate files for each of the plugins (cf. Electron apps or Homebrew formulae). This way, when I as a plugin maintainer add my plugin, it does not conflict with other pending contributions. I believe this could happen when everybody starts to modify the same array in a single JSON.
Good thought, but this would need an extra bundling step to put all the JSON files together into one, right? With a simple file, one can easily access it, e.g. via https://raw.githubusercontent.com/camunda/camunda-modeler-plugins/master/plugins.json.
Indeed, that would make the pipeline more complicated.
I think adding a plug-in to a JSON file is absolutely manageable.
Combine that with a simple GitHub Action that verifies the JSON file against a defined JSONSchema and we're good.
What shall we do
As a integration author I love to discover available plug-ins in a structured manner. At the same time I'd like to understand an individual plug-ins context (i.e. compatibility) in a structured manner (currently represented as a compat table + badge)), too.
Why shall we do it
Providing both in a structured way allows us to build tooling for plug-in discovery, installation, and upgrading (i.e.
mopl
, just without crawling).