Define our own, rather minimal interface so that we change the parser
under the hood if ever needed, I already did so once during
evaluating this, as first I checked out Snarkdown[0], which is really
nice for the few lines of code it needs, but is a bit to limited for
the use case.
Currently marked[1] is used, provided by the libjs-marked Debian
package.
For now statically link the marked parser in on built time to avoid
the need to add new directories to serve in our pve/pmg/pbs proxies.
This is a bit ugly but can be cleaned up afterwards transparently
too.
We sanitize the produced HTML ourselves (most MD JS parser/renderer
don't do that) by creating a real, but not active, DOM tree and
recursively prune bad nodes/attrs from it and let it spit out HTML
again at the end. While a tad inefficient it really won't matter for
our use case, as the notes/comments we render are only a few KiB of
text and it's done on the client side anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
used for various other packages to dev-depend on (e.g. pve-docs)
which only contains the Toolkit.js for now
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
