Hi, I wonder where I can find info about the possibility (or the decision of not having a possibility) to incorporate add-ons or plug-ins to HedgeDoc. If it is not possible and the decision was that, I would then ask if is recommended and maybe how to do dirty hacks to put enchantments at least in a particular instance.
You can always fork HedgeDoc and build your own version. This is why it’s FOSS.
The Code of HedgeDoc 1 is a total mess. Also it’s feature complete. We won’t implement something like that for version 1.
Extension/Add-On-Support for HedgrDoc 2 is something that we discussed a few times but haven’t decided on anything yet.
The problem is that extension systems are a huge pile of work. We would have to rewrite code to make it more general and make sure that the extensions wouldn’t influence each other. We would have to test this extension points meticulously. We would have to write tons of documentation. We would have to think about a concept how we inform people that (if bugs occur) the error/wrong behavior they experience rn is not our fault.
Also the 2.0 is far from being finished. The code structure is still changing a lot.
Don’t expect it for version 2.0. Maybe sometime after that version. Please let us implement the basics first. 
I have thought this fight multiple times. Requests for plugins are a regular thing. My experience with plugin systems is regularly bad. Why?
- They are hard to maintain.
As soon as you introduce a plugin system, you have to maintain a stable API. You have to figure out plugin compatibility and you can not tell if a change might breaks any plugin in an unexpected way. - They usually result in a lot of low quality plugins.
Besides broken plugins, most plugin systems result in a ton of plugins that are of bad quality. From unmaintained plugins to plugins plagued with vulnerabilities either intentionally or unintentionally. And as long as they solve a problem, they will be used at any cost. - Bad/wrong error reports.
Most software that has a plugin system will get more bug reports that are not affecting the vanilla version of the software resulting in unneeded work for the developers. Those are usually caused by plugins that have some sort of side effect or used an API they are nor supposed to use. - Making bug reports harder
As if reproducing a bug isn’t already hard enough for reporters, it’s even harder when you always have to ask them to disable all plugins first. If I’m running a production environment, that’s a big no-no. So I have to set up a test instance without plugins, then reproduce the bug, then try to reproduce it, etc. Usually I as a bug reporter stop reporting at “setup a test environment without plugins”.
What is the alternative?
Properly developed features. If you want to integrate a functionality in HedgeDoc, work with us. It not only makes sure that everyone benefits from the feature, but also that the feature is maintained and ported to new versions.
What if your feature will not make it into HedgeDoc due to concerns?
Fork it. HedgeDoc welcomes forks. Forks make the ecosystem more diverse and help innovation. At the same time, it helps you to feel potential problems that developers might saw with your feature. At the same time, it helps us to see the real value of your contribution. So while it might didn’t convince us on the spot, maybe a few iterations later, it looks more appealing.
Well, if that feature comes to light, I can help with the spanish documentation. The issue about the fork is that if later I want to update, it would be a headache. But maybe for injecting some extra javascript files, where should I start to look at?
I agree with the things you pointed out, I have seen that in other platforms, until the point that it is tedious to find a plugin that works. Maybe I should rewrite the question of this post, how it could be possible to extend HedgeDoc functionalities that avoids the plugin hell but also allows certain flexibility without doing a fork?
I mean, I would like to collaborate in developing features an even though JavaScript and Ruby are the langs that I know, my knowledge is very limited and as we say in Spanish: “Mucho ayuda el que no estorba” [The best way to help is not to get in the way]. About the forks, I try to stay away from them until I have a disagreement of some sort.
In this frame, something that I have been thinking is to use HedgeDoc trough its API so I can messy-develop a frontend with the things I want to try. I guess it is something that it is gonna change radically for v2.0. By the way, nice cli tool, I hope one day I can implement a ruby gem for HedgeDoc API 
I understand that plugin systems are a lot of work, but I think apis should always be stable and backward compatible.
The second point, could be fought by having a plugin repository and big warnings if there are plugins installed, that are not in the repository. But checking each plugin would probably be a lot of work.
For solving points 3 and 4 you would need to have a “safe mode” which temporarily disables all plugins. You could maybe disable front end javascript and add extra http parameters to requests to do that.
The advantage of plugins is that you can add features with specific use cases, most people won’t need. I think octoprints plugin system is pretty good.
Hm. I like software, which is plugin friendly from the core like discourse or obsidian.
From my point of view hedgedoc development seems to have stalled.
Plugins from the core might support evolution.
From my point of view hedgedoc development seems to have stalled.
What is your point of view? The general development of HedgeDoc is everything but not stalled. We’re working on a complete rewrite for two years now as you can see on GitHub.
Only version 1 is in maintenance mode and won’t get new features because it’s messy (which is the reason why we’re doing the rewrite).