Add remark-mdx-remove-expressions to list of plugins

[talatkuyuk]

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

If MDX content is not fully trusted, then Remote Code Execution (RCE) is inherently possible. This is clearly documented in MDX and related integration package documentation.

Lately, it is reported that the critical vulnerability CVE-2026-0969 may cause RCEs.

remark-mdx-remove-expressions is a remark plugin that removes MDX expressions.

It is a remark plugin to sanitize MDX content by removing JS expressions for enhanced security, allowing you to explicitly control JS expression handling in MDX.

It can remove all JS expressions from MDX content, but it is more suitable to use safer balanced mode (recommended) removes only dangerous MDX expressions:

import remarkMdxRemoveExpressions from "remark-mdx-remove-expressions";

{
  mdxOptions: {
    remarkPlugins: [
      [remarkMdxRemoveExpressions, { onlyDangerousExpressions: true }]
    ]
  }
}

This change adds remark-mdx-remove-expressions to the plugin list in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (1b31316) to head (6d6167f).

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #2677   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           21        21           
  Lines         2649      2649           
  Branches         2         2           
=========================================
  Hits          2649      2649           

☔ 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.

[remcohaszing]

Thanks!

[ChristianMurphy]

Thought and suggestion, would it be possible to move the ad and sponsors to under where the project description and when to use are?
It feels kinda abrasiveness to have to scroll through a wall of ads and sponsors to figure out if this package even makes sense to use.

[talatkuyuk]

I haven't received any negative feedback regarding this layout until now.

In all the packages I've published, I preferred to place the sponsors and ads section at the very top, even before the project name, I try to keep that section very brief.

However, I will take your suggestion into consideration. I might plan this as a collective update across all my packages.

[ChristianMurphy]

I get it's a tricky balance, needing revenue sources like sponsors/ads etc to fund your work.
Putting all that at the top, reminds me a bit of the terminal ads drama of 2019 https://www.zdnet.com/article/npm-bans-terminal-ads/ where they were so aggressively printed it was hard to work, and ads/sponsor header in the readme similarly falls in a place where it gets harder to get to the info people want/expect/need with it, where a footer doesn't have that same negative effect.