ESM.sh 项目中的 Deno 2 兼容性问题解析

在 JavaScript 生态系统中，模块加载和跨环境兼容性一直是开发者面临的挑战。ESM.sh 作为一个提供 ES 模块 CDN 服务的项目，其核心目标是为开发者提供稳定可靠的模块分发服务。近期，随着 Deno 2.0 的发布，一些兼容性问题逐渐浮出水面，特别是关于全局变量处理的差异。

Deno 2.0 移除了 window 全局变量，这一变化直接影响了 ESM.sh 中部分模块的构建输出。问题的根源在于 ESM.sh 的构建过程中，某些代码转换逻辑错误地将 typeof window 检查替换为了 typeof Deno 检查。这种替换在 Deno 1.x 中可能不会引发问题，但在 Deno 2.0 及 Web Workers 环境下就会导致 window is not defined 的错误。

具体到 Preact 开发工具模块的案例中，构建后的代码包含了对 window.__PREACT_DEVTOOLS__ 的访问，但由于错误的变量替换，代码在 Deno 2.0 环境下无法正常运行。类似的问题也出现在其他模块中，如 openapi-typescript 所依赖的 Node.js 内置模块 polyfill。

ESM.sh 团队迅速响应了这一问题。他们首先定位到早期版本中存在的代码替换逻辑，确认该问题已在后续版本中修复。但由于构建缓存机制，旧的错误构建结果仍然存在于存储系统中。团队采取了手动清除过期模块的措施，并要求开发者使用 --reload 标志重新获取最新构建结果，从而确保获取到修复后的正确版本。

对于开发者而言，这一事件提供了几个重要启示：

1. 在环境假设上要谨慎，特别是在处理全局变量时
2. 跨运行时兼容性需要特别关注不同环境的差异
3. 缓存机制虽然能提高性能，但也可能导致过时代码的滞留
4. 使用 --reload 标志可以强制获取最新构建，是解决类似缓存问题的有效手段

随着 JavaScript 生态的不断发展，类似的环境差异问题可能会持续出现。ESM.sh 团队的处理方式展示了开源项目应对兼容性挑战的标准流程：快速定位问题、明确影响范围、实施修复方案并通知用户解决方案。这种响应模式值得其他项目借鉴。