ESLint 核心规则探讨：为什么我们需要禁止顶层 await

在 JavaScript 生态系统中，ESLint 作为代码质量保障的重要工具，其核心规则的制定往往反映了开发者社区对最佳实践的共识。近期，关于是否应该在 ESLint 核心中添加禁止顶层 await（Top-Level Await，简称 TLA）规则的讨论引起了广泛关注。

顶层 await 的技术背景

顶层 await 是 ECMAScript 模块系统中的一个特性，它允许开发者在模块的最外层直接使用 await 表达式，而不必将其包裹在异步函数中。这个特性看似便利，实则带来了几个重要的技术考量：

1. 模块加载行为改变：使用顶层 await 的模块会变成"异步模块"，这意味着导入该模块的代码必须等待其异步操作完成才能继续执行
2. 兼容性问题：特别是在 Node.js 环境中，当通过 require() 加载包含顶层 await 的 ESM 模块时，会导致运行时错误
3. 工具链支持：部分构建工具和转译器对顶层 await 的支持还不够完善

实际开发中的痛点

在混合使用 CommonJS 和 ESM 模块的项目中，顶层 await 可能成为隐形的"陷阱"。开发者可能无意中在 ESM 模块中使用顶层 await，然后通过 Node.js 的 require(esm) 功能加载该模块，导致难以调试的运行时错误。

TypeScript 目前也无法在类型检查阶段捕获这类问题，使得这类错误更容易进入生产环境。对于库开发者而言，如果在发布的 ESM 模块中使用了顶层 await，会强制所有依赖该库的代码也必须以异步方式加载模块。

技术权衡与替代方案

虽然顶层 await 在某些场景下确实有用（如 CLI 脚本），但在大多数库和应用程序代码中，它带来的问题多于便利。更合理的做法是：

1. 将异步操作封装在明确的异步函数中
2. 在模块边界处明确处理异步性
3. 使用立即执行的异步函数表达式来替代顶层 await

现有的 eslint-plugin-es-x 已经提供了 no-top-level-await 规则，而 Node.js 特定的检查可以考虑通过 eslint-plugin-n 实现。虽然这些方案都能解决问题，但将其纳入 ESLint 核心规则可以提高规则的可见性和采用率。

总结

禁止顶层 await 的核心诉求是提高代码的可预测性和兼容性。在 JavaScript 模块系统日益复杂的今天，明确控制异步行为的位置和范围，对于构建健壮的应用程序至关重要。虽然这次讨论最终决定不将其加入 ESLint 核心规则，但这个话题本身反映了 JavaScript 生态系统中模块加载和异步处理这一持续演进的技术挑战。