Excalidraw项目中的环境变量优化实践

在Excalidraw项目的开发过程中，团队发现直接使用import.meta.env来获取环境变量存在一些潜在问题。本文将详细介绍这一优化过程的技术细节和实现方案。

背景与问题

Excalidraw是一个开源的虚拟白板工具，在开发过程中需要区分不同的运行环境（开发环境、测试环境等）。原代码中直接使用了Vite提供的import.meta.env.DEV和import.meta.env.TEST来判断当前环境，这种方式存在几个缺点：

1. 直接依赖构建工具的特定实现，降低了代码的可移植性
2. 环境判断逻辑分散在各处，不利于统一维护
3. 类型安全方面存在隐患

解决方案

团队决定将这些环境判断封装成独立的工具函数，主要实现了两个核心函数：

1. isDevEnv() - 判断是否为开发环境
2. isTestEnv() - 判断是否为测试环境

这种封装带来了以下优势：

• 统一了环境判断逻辑，所有相关代码都集中管理
• 提高了代码的可测试性
• 增强了类型安全性
• 降低了与特定构建工具的耦合度

实现细节

在实现过程中，团队特别注意了以下几点：

1. 函数实现位于packages/excalidraw/utils.ts文件中
2. 通过搜索import.meta.env.MODE找到所有需要替换的代码位置
3. 确保测试用例覆盖了所有环境判断场景
4. 对于@excalidraw/excalidraw包中未暴露的测试工具，进行了适当的暴露处理

最佳实践

基于这次优化，可以总结出一些前端项目环境变量管理的最佳实践：

1. 避免直接使用构建工具提供的环境变量
2. 将环境判断逻辑封装成独立的工具函数
3. 确保环境判断逻辑集中管理
4. 为环境判断函数编写完善的测试用例
5. 考虑跨构建工具的兼容性

总结

Excalidraw项目通过将环境判断逻辑封装成独立函数，提高了代码的可维护性和可测试性。这种模式值得在其他前端项目中借鉴，特别是那些需要区分多种运行环境的复杂应用。通过抽象环境判断逻辑，项目可以更好地适应不同的构建工具和部署场景。