Added Remark plugin

[naiyerasif]

This change adds a Remark plugin to process markdown with Remark and generate the subsequent HTML with Rehype.

I have used esm.sh as the import host because that's what most of the Remark and Rehype ecosystem prefers.

[oscarotero]

Thanks, @naiyerasif I'm wondering if we can create two different plugins, one for remark and other for rehype. In this way, users could use rehype plugins with any html, not only those generenated from markdown (for example, to process html from nunjucks, jsx, etc).

[naiyerasif]

@oscarotero Remark and Rehype can indeed be used as standalone processors. I'll explore how best this can be done.

[naiyerasif]

I have done some changes:

• The responsibility to load the plugins is now deferred to Unified.
• An option preset was added to create a custom configuration that would completely override all the opinions in the plugin. This might be useful for people who might want a different markdown spec (GFM is the default one configured in the plugin).

[oscarotero]

Hi, that looks pretty good!

I have a couple of comments, let me know your opinion:

• I wouldn't add the preset option. It makes the plugin too open, and allows to use it even without runing remark/rehype, which is weir for a plugin supposed to render markdown. If some customization is needed, maybe remarkOptions and rehypeOptions could be enough.
• I'd register only one filter, the sync version (but with md name, instead of mdSync). Sync filters are better (in general) and I guess the output code is the same in both cases.

[naiyerasif]

Hey Oscar,

• I'm fine with removing the support for presets.
• I'm also ok with renaming mdSync to md. However, note that Remark is primarily designed for async workflows and some Remark / Rehype plugins may not work correctly with synchronous processing. Therefore, I would recommend to leave an mdAsync filter so that people can fallback to it if something goes wrong.

Thoughts?

[oscarotero]

Ok, in that case it's needed to register it as async filter adding true to the third argument:

site.filter("mdAsync", asyncFn, true);

btw: is there any way to detect if async filter is needed? I'm thinking in register only one the md filter but set it sync or async depending on the plugins used (or maybe adding an option to the plugin configuration).

[naiyerasif]

I have done the suggested changes (removing preset support and renaming md and mdSync filters to mdAsync and md respectively.

btw: is there any way to detect if async filter is needed? I'm thinking in register only one the md filter but set it sync or async depending on the plugins used (or maybe adding an option to the plugin configuration).

Unfortunately, the current Processor and Plugin API does not surface this information so it cannot be done without some ugly hack.

[naiyerasif]

One another thing about this plugin: it does not generate safe HTML. This is by intent so that people can inject raw HTML and MDX. Would it make sense to introduce an option to generate sanitized HTML?

[oscarotero]

Yeah, I think it's fine to allow raw HTML by default and add an option to disable it.

[naiyerasif]

Done. A sanitize flag will let users switch on HTML sanitization. I'll have to add a note about this in the docs reminding that this might affect MDX and any other plugin that generates raw HTML.

[oscarotero]

Ok, It looks good to me. Can I merge it?

[naiyerasif]

Sure. I'll work on some docs when you think this can be promoted to main repo.