Add @m2d/remark-docx to the plugins list

[mayank1513]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and discussions and couldn’t find anything or linked relevant results below
• I made sure the docs are up to date
• I included tests (or that’s not needed)

Description of changes

• 🟢 @m2d/remark-docx
  — compile markdown to docx with support for GFM, tables, html, and more.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (a185821) to head (6349f8d).
Report is 41 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1431   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            6         6           
  Lines          142       138    -4     
=========================================
- Hits           142       138    -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ChristianMurphy]

Thanks for sharing @mayank1513! 🙇
A few thoughts:

• remark plugins are generally run in node, but the ts config seems to indicate this is a react app? https://github.com/tiny-md/mdast2docx/blob/622df0a6fb59133803b2b1be5e429cd443c15994/m2d/mdast/tsconfig.json#L2-L4
• dual packaging ESM and CJS has a lot of hazards, and isn't really needed any more (CJS can now import ESM in new versions of node) consider packaging this only as ESM https://github.com/tiny-md/mdast2docx/blob/622df0a6fb59133803b2b1be5e429cd443c15994/m2d/mdast/package.json#L8-L19
• peerDependencies work very inconsistently across different package managers, consider moving docx to be a direct dependency https://github.com/tiny-md/mdast2docx/blob/622df0a6fb59133803b2b1be5e429cd443c15994/m2d/mdast/package.json#L39-L41
• This package doesn't appear to have a stable release? it's still labelled as alpha with 0.0.2 being latest https://www.npmjs.com/package/@m2d/mdast/v/0.0.2
• We already provide strong types for mdast, install @types/mdast to use them https://github.com/tiny-md/mdast2docx/blob/main/m2d/mdast/src/index.ts
• unified and mdast provide visitor patterns https://www.npmjs.com/package/unist-util-visit was there a particular need not met that you custom wrote another? https://github.com/tiny-md/mdast2docx/blob/622df0a6fb59133803b2b1be5e429cd443c15994/m2d/list/src/index.ts#L111

[mayank1513]

Thank you for the feedback.

1. I am trying to support both, node.js and browser environments. In my case, I needed to convert to docx on client side. However, the package supports both client and server. With a few more features on client side compared to server side at the moment.

2. Thanks for the suggestion. Can you please let me know a bit more about the hazards.

3. Thanks, Will fix ASAP

4. @m2d/mdast is extended version of @types/mdast to support fragments and a few other custom nodes. This is used only internally and for @m2d/* plugins.

5. I will go through the visitor pattern and see if I can implement it here. The idea here is to support extending the functionality of core engine via plugins. Example of official plugins - @m2d/html, @m2d/table, @m2d/image, etc. A few more handling yaml, code styling, etc. are planned to be released soon.

[mayank1513]

Publish a patch - moving docx to deps instead of peerDeps

[JounQin]

@mayank1513
The link in PR description is wrong.
Please change the PR title more meaningful.

[ChristianMurphy]

Thanks for the suggestion. Can you please let me know a bit more about the hazards.

https://github.com/GeoffreyBooth/dual-package-hazard?tab=readme-ov-file#dual-package-hazard

[mayank1513]

https://github.com/GeoffreyBooth/dual-package-hazard?tab=readme-ov-file#dual-package-hazard

Thanks, for now I think going with both CJS and ESM is good option. I do not find this very likely to happen. Besides, I have seen some companies still using some packages that are officially discontinued. So, I find it safer to allow both ESM and CJS as long as docx is supporting both.

[mayank1513]

@mayank1513 The link in PR description is wrong. Please change the PR title more meaningful.

Done. Thank you!

[ChristianMurphy]

Thanks, for now I think going with both CJS and ESM is good option. I do not find this very likely to happen. Besides, I have seen some companies still using some packages that are officially discontinued. So, I find it safer to allow both ESM and CJS as long as docx is supporting both.

ESM only exports supports both CJS and ESM, in node 20+ https://nodejs.org/en/blog/release/v20.19.0#requireesm-is-now-enabled-by-default

[mayank1513]

Agree, but not everyone is on or above node 20 Mayank Kumar Chaudhari Software Architect (Focus Front End) | Microsoft Certified Expert https://mayank-chaudhari.vercel.app/

…

On Fri, Mar 28, 2025 at 5:24 PM Christian Murphy ***@***.***> wrote: Thanks, for now I think going with both CJS and ESM is good option. I do not find this very likely to happen. Besides, I have seen some companies still using some packages that are officially discontinued. So, I find it safer to allow both ESM and CJS as long as docx is supporting both. ESM only exports supports both CJS and ESM, in node 20+ https://nodejs.org/en/blog/release/v20.19.0#requireesm-is-now-enabled-by-default — Reply to this email directly, view it on GitHub <#1431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCR4VPC6NTAQRNK7EBICH32WU2ANAVCNFSM6AAAAABZT7CXTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRRGE2TAMJRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: ChristianMurphy]*ChristianMurphy* left a comment (remarkjs/remark#1431) <#1431 (comment)> Thanks, for now I think going with both CJS and ESM is good option. I do not find this very likely to happen. Besides, I have seen some companies still using some packages that are officially discontinued. So, I find it safer to allow both ESM and CJS as long as docx is supporting both. ESM only exports supports both CJS and ESM, in node 20+ https://nodejs.org/en/blog/release/v20.19.0#requireesm-is-now-enabled-by-default — Reply to this email directly, view it on GitHub <#1431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCR4VPC6NTAQRNK7EBICH32WU2ANAVCNFSM6AAAAABZT7CXTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRRGE2TAMJRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[JounQin]

I personally think dual package is fine vs ESM only in near future.

[ChristianMurphy]

Agree, but not everyone is on or above node 20

Node 18 is days away from being unsupported
https://nodejs.org/en/about/previous-releases#release-schedule

If you want to take time to support releases the Node foundation no longer support, you can 🤷

[mayank1513]

Thanks. Will rethink in a month or two.