feat: add support for plugins

[szymonograbek]

📝 Description

This PR adds support to pass plugins to the processor, so we can use i.e. rehypeParse and rehypeRemark to parse HTML to markdown. I've added temporal samples as typescript files to test this locally, if this PR will be accepted then I'll move them to the rest of markdown files.

📌 Related Issue

Link: #43

📷 Screenshots

Parsed HTML:

✅ Checklist

• My PR title follows the Conventional Commit format (e.g. feat:, fix:, chore:)
• This PR addresses the related issue (if applicable)
• I have attached a sample Markdown file (.md) used for testing
• I have attached at least one screenshot of the rendered output (light and/or dark mode preferred)
• I have run pnpm run lint:fix to fix formatting and lint errors
• I have tested the changes in the example app (pnpm i && cd example && pnpm i && pnpm run ios)

[imwithye]

@szymonograbek Thank you! I will take a look these days.

[LouisDvr]

I'm excited by the support for plugins so I had a look at that part of the PR to try and fasten its inclusion in the lib. Thanks for doing it!

As I commented, I think considering remark-parse like an optional plugin leads to problems so I would recommend forcing its usage

Also, this comment in the original issue even recommends to drop suggested plugins and let users use whichever plugin they need. It could reduce the bundle size to avoid importing remark-gfm in all cases but I wonder if it wouldn't be misleading to say the lib support GFM (because it includes the appropriate renderers) while still requiring users to pass the plugin manually. Wdyt @szymonograbek and @imwithye ?

Finally, I think adding a mermaid example isn't really linked to adding support for custom plugins, though originating from the same discussion, so it would be cleaner to put it in a separate PR to avoid bloating this one and ease the review and acceptance or not of each subject (mermaid example represents more than 98% of the changed lines)

[LouisDvr]

And here

Suggested change

	return unified().use(remarkPlugins);
	return unified().use(remarkParse).use(remarkPlugins);

[LouisDvr]

I think remarkParse shouldn't be included in the default plugins and the lib should rather use it by default because

1. users can pass an empty array, which would lead to a runtime error (TypeError: Cannot "processSync" without "Parser")
2. remarkParse is the official remark parser so users will always want to use it when customizing the plugins list so using it by default would reduce the boilerplate

This would give

Suggested change

	const defaultRemarkPlugins: PluggableList = [remarkParse, remarkGfm];
	const defaultRemarkPlugins: PluggableList = [remarkGfm];

[szymonograbek]

As I commented, I think considering remark-parse like an optional plugin leads to problems so I would recommend forcing its usage

Also, this comment in the original issue even recommends to drop suggested plugins and let users use whichever plugin they need. It could reduce the bundle size to avoid importing remark-gfm in all cases but I wonder if it wouldn't be misleading to say the lib support GFM (because it includes the appropriate renderers) while still requiring users to pass the plugin manually. Wdyt @szymonograbek and @imwithye ?

I've though about it and I agree, we should keep remark-parse as a non-optional. This would follow how react-markdown works. I'm not sure what to do with remark-gfm - I think we should do as you say and mention that the library supports GFM, but to parse it developers should install and add the plugin. I'll leave the decision to the library owner.

Finally, I think adding a mermaid example isn't really linked to adding support for custom plugins, though originating from the same discussion, so it would be cleaner to put it in a separate PR to avoid bloating this one and ease the review and acceptance or not of each subject (mermaid example represents more than 98% of the changed lines)

Sure, I've removed it from this PR

[imwithye]

Thank you for your PR! I will review it this week. Overall, it looks good to me!