Add remark-cloudinary-docusaurus to list of plugins

[johnnyreilly]

Signed-off-by: John Reilly johnny_reilly@hotmail.com

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)
• If applicable, I’ve added docs and tests

Description of changes

This PR adds a link to the remark-cloudinary-docusaurus plugin - I hope I've done that correctly! More details on the plugin here: https://blog.johnnyreilly.com/2022/12/26/docusaurus-image-cloudinary-remark-plugin

[johnnyreilly]

I thought I used the correct marker.... Not sure why it's erroring?

[codecov-commenter]

Codecov Report

Merging #1090 (8dbd6a5) into main (28aa8b9) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1090   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines          906       906           
=========================================
  Hits           906       906           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 28aa8b9...8dbd6a5. Read the comment docs.

[ChristianMurphy]

Welcome @johnnyreilly!
Thanks for sharing!

Hopefully docusaurus will have ESM support soon, it sounds like progress is being made towards facebook/docusaurus#6520, CJS is a bit out of step with most of the remarkjs plugins.

In the meantime some suggestions;

• It looks like this has now become a rehype plugin, it may more sense to add this to the plugin list in https://github.com/rehypejs/rehype rather than here
• consider using the Plugin type to declare your plugin (e.g. https://github.com/remcohaszing/remark-mdx-frontmatter/blob/fa93b864749f1994a82211a07b18bc5e922becfc/index.ts#L81 or https://github.com/rehypejs/rehype-highlight/blob/d05e0023fce8a7659abcbc0f86b18bd1fa62c188/lib/index.js#L43)
• Consider using @types/hast to get pre-made typings for all of the supported node types. Using the Root node with the Plugin type will allow TypeScript to infer a lot more about the data structures you are working with, and the hast types can be used in the visitor as well.
• If you're looking to trim the dependencies and build layers a bit vitest probably isn't needed and could be replaced by node:test https://nodejs.org/dist/latest-v18.x/docs/api/test.html
• TypeScript has a different/looser interpretation of semver, breaking changes can be included in minor versions, when listing it at a dependency https://github.com/johnnyreilly/rehype-cloudinary-docusaurus/blob/06d3a34f884c1188aa58d031b7cccc42d252e3c9/package.json#L33 Consider using a patch version range ~, or if you keep it as ^ expect breakage every now and again.
• I'd be cautious making libraries directly used by the project peerDependencies https://github.com/johnnyreilly/rehype-cloudinary-docusaurus/blob/06d3a34f884c1188aa58d031b7cccc42d252e3c9/package.json#L57-L59 unless there is a really good and really specific reason for peerDependencies, make direct dependencies and type dependencies plain dependencies.

[wooorm]

Thank you!