MDX-React 在 Next.js 中因重复 React 包导致的 useContext 错误解析

在大型前端项目中，特别是使用 Monorepo 架构时，开发者经常会遇到依赖管理的问题。最近在 MDX 和 Next.js 集成场景中出现了一个典型问题：当使用 Yarn 1 的 nohoist 功能时，系统会抛出"无法读取 null 的属性（读取 'useContext'）"的错误。

这个问题的根源在于 React 包的重复加载。在 Monorepo 结构中，当使用 Yarn 1 的 nohoist 功能来管理 @mdx-js/react 依赖时，可能会导致多个版本的 React 包被同时加载。具体表现为：

1. 一个 React 包存在于根目录的 node_modules 中
2. 另一个 React 包存在于子包的 node_modules 中

这种重复加载会导致 React 的上下文系统出现问题，因为 React 期望在应用中只有一个实例运行。当 MDX 尝试使用 useContext 钩子时，由于 React 实例混乱，就会抛出上述错误。

解决这个问题有两种主要方法：

第一种方法是完全移除 nohoist 配置。这可以让 Yarn 按照默认方式处理依赖提升，确保只有一个 React 实例被加载。但这种方法可能不适合所有项目，特别是那些确实需要不同版本依赖共存的情况。

第二种方法更为精细，即在 nohoist 配置中显式包含 React 包。通过将 React 也加入 nohoist 列表，可以确保所有子包都使用同一个 React 实例。配置如下：

{
  "workspaces": {
    "nohoist": [
      "**/@mdx-js/react",
      "**/@mdx-js/react/**/*",
      "**/react"
    ]
  }
}

从技术原理上看，这个问题揭示了前端依赖管理中的几个重要概念：

1. 单例模式的重要性：像 React 这样的库设计为单例运行，多个实例会导致内部状态系统混乱
2. 包管理器的提升机制：不同包管理器对依赖解析的策略差异可能导致微妙的问题
3. Monorepo 中的依赖隔离：在大型项目中平衡依赖共享与隔离需要谨慎设计

对于使用现代前端技术栈的开发者，建议考虑升级到 Yarn 2+ 或 pnpm 等现代包管理器，它们提供了更可靠的依赖解析机制。同时，在 Monorepo 架构中，应该建立明确的依赖管理策略，特别是对于像 React 这样的核心库。

这个问题虽然表现为一个错误提示，但背后反映的是前端工程化中依赖管理的深层次挑战。理解这些原理有助于开发者构建更稳定、可维护的大型应用。