EnvSync-LE

EnvSync-LE：轻松同步 .env

在 .env 文件中找出缺失的键，避免问题发生
自动检查、状态栏计数器，以及简洁的 Markdown 报告

觉得有用？ 点赞或评分能帮助其他开发者发现它 — ★ GitHub · ★ Open VSX · ★ Marketplace

功能介绍

EnvSync-LE 会比较工作区中 .env 文件的变量名，并指出哪些文件缺少哪些键。它绝不会读取或比较变量值，也不会修改你的文件。支持 VS Code 及基于 VS Code 的编辑器，例如 Cursor 和 VSCodium（可从 Open VSX 安装）。

• 自动检查 — 每当受监视的 .env 文件发生变化，都会运行防抖同步检查
• 状态栏计数器 — 显示当前问题数量，单击即可查看完整报告
• Markdown 报告 — Show Details 会列出每个文件缺少的所有键
• 三种比较模式 — auto（所有键的并集）、manual（仅比较你列出的文件）、template（根据一个参考文件验证所有内容；也会报告文件中存在但模板中缺少的键）
• 忽略列表 — 暂时排除文件（例如 .env.example），不对其进行检查

安装

在 AI Agent 中使用

同一引擎也可作为 MCP 服务运行，因此 Agent 可以直接调用它，而不必由你运行命令。

compare_env_files(files[], mode?, templatePath?, caseSensitive?, maxResults?)

直接接收文件内容，并报告哪些文件缺少哪些键。只返回键名，绝不返回值 — dotenv 文件存放着凭据，而回答并不需要这些值。

该服务接收内容并返回数据 — 不会读取任何文件，也不会自行发出网络请求。它以 envsync-le-mcp 的名称发布在 npm 上，并以 io.github.nolindnaidoo/envsync-le 的名称发布在 MCP 注册表中。

{
  "mcpServers": {
    "envsync-le": {
      "command": "npx",
      "args": ["-y", "envsync-le-mcp"]
    }
  }
}

npm install -g envsync-le-mcp

{
  "mcpServers": {
    "envsync-le": { "command": "envsync-le-mcp" }
  }
}

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | npx -y envsync-le-mcp

文件分类

分类依据基名中的片段 — app.device.env 不属于 “开发环境”，且 Windows 路径也能正确分类。

命令行工具

同一比较功能也可在终端或 CI 步骤中运行：Rust 命令行工具位于 crate/，与扩展共享一个样本集 — crate/fixtures/ — 因此两者读取 dotenv 文件的方式 绝不会不同。 可以通过 npm 安装：npm install -g envsync-le（或使用 npx envsync-le 运行）；也可以通过 crates.io 使用 cargo install envsync-le 安装。两种方式 安装的是同一条命令，输出也逐字节保持一致。

envsync-le .                            # have these environments drifted? JSON on stdout when piped
envsync-le --template .env.example .    # will this deploy break?
envsync-le mcp                          # the same comparison over MCP on stdio

可从 npm (envsync-le) 或 crates.io 安装 (envsync-le)。两种方式安装的都是同一个 envsync-le 命令。

npm install -g envsync-le   # or run it once: npx envsync-le
cargo install envsync-le

.env: missing STRIPE_KEY, SENTRY_DSN (in .env.example)
.env.production: missing SENTRY_DSN (in .env.example)
out of sync — 2 files with mismatches across 3 files

退出代码就是结果 — 同步时为 0，不同步时为 1，问题格式错误时为 2。 完全找不到 dotenv 文件时返回 0：没有任何文件可与之不同步。与此系列中的提取工具不同，它没有列表可供 继续传递；这个数字就是答案。

它绝不读取任何值。 只会解析、比较或 报告键名，并通过三项独立检查来确保这一点，而非仅作承诺。

命令

默认情况下，没有命令绑定快捷键。可在编辑器的 键盘快捷方式 中为任意命令绑定快捷键。

设置

解析说明

• 键必须匹配 [A-Za-z_][A-Za-z0-9_.-]*，因此 spring.datasource.url 这类带点的名称也有效；= 左侧的任何其他内容都会被报告为该行的解析错误（文件其余部分仍会计入）。
• 接受 export KEY=value；重复的键只计一次。
• 用 "、' 或 ` 引起来的值可以跨越多行；未闭合的引号会被报告为错误。
• 在 auto 模式下，参考键集合是所有键的并集，因此只有在 template 模式下才会出现“额外键”。

语言

除英语外，还有十二种语言：

德语 · 西班牙语 · 法语 · 印度尼西亚语 · 意大利语 · 日语 · 韩语 · 葡萄牙语（巴西）· 俄语 · 乌克兰语 · 越南语 · 简体中文

两个部分都已翻译：清单（命令标题、设置名称和描述），以及扩展运行时显示的所有内容（通知、状态栏、快速选择和提示词，以及报告标题）。帮助页面以英语编写。扩展会遵循 VS Code 的显示语言，因此会与编辑器当前设置的语言一致；扩展本身没有单独的语言设置。

隐私与安全

• 不访问网络。 此扩展绝不会向任何地方发送数据。telemetryEnabled 设置只会将事件写入本地输出通道，供你查看（envsync-le）。
• 绝不会读取、显示或记录值——只比较键名。
• MCP 服务只返回键名，绝不返回值。 凭证存放在 dotenv 文件中，因此服务只报告缺少或多余的键，不会透露其内容。它将文件内容作为参数，而非路径，因此不会读取任何文件，也不会发起网络调用；打包门禁会断言响应中不含已知值。
• 错误通知会对主目录和类似凭证的片段进行脱敏。
• 评分提示最多出现两次。 第 3 次成功使用时，扩展会询问你是否愿意评分；如果你选择了 稍后 或将其关闭，则会在第 20 次使用时再询问一次。选择 不再询问 后便不会再提示。你自行将 notificationLevel 设置为 important 或 silent，也会关闭此提示。计数保存在 VS Code 的扩展存储中，不会向任何地方发送数据；点击 评分 会在浏览器中打开你安装时使用的发布平台页面——VS Code Marketplace 或 Open VSX。

文档

性能

预热后运行 7 次取中位数，测试环境为 Apple M5 Pro、24 GB RAM、Node 24.3.0。输入由 scripts/benchmark.ts 生成，而非签入仓库，因此上述大小与实际测量值完全一致。运行 bun run benchmark 可复现。

这些数据因机器而异，不会在 CI 中断言——会阻止构建的基准测试，只能说明运行器当时有多忙。

测试

28 个文件中共有 353 个测试用例，此外还有一个在真实 VS Code 扩展宿主中运行的集成测试套件，以及一个将构建好的 .vsix 安装到全新配置文件中的端到端测试。

数据由 scripts/coverage-readme.js 根据真实运行生成——文件为 coverage/coverage-summary.json 和 coverage/test-results.json；如果此部分内容有偏差，CI 会失败。运行 bun run test:coverage 可复现，用例数以 vitest 打印的结果为准。

LE 系列的更多工具

为每个模型眼前的工作打造的 16 款单一用途工具。每款都附带一个 Rust CLI 和一个 MCP 服务。一页尽览：letools.dev

提取

• String-LE — 提取代码库中的所有字符串，方便人工阅读
• Numbers-LE — 提取代码库中所有硬编码数字，方便人工检查
• Units-LE — 提取所有带单位的数量并统一格式，遇到含义不明确的数量时会按名称拒绝处理
• Dates-LE — 提取所有日期和时间戳，并给出每个日期和时间戳解析出的确切时刻
• IDs-LE — 提取所有 UUID、ULID、NanoID、ObjectId 和 Snowflake，并解码其中的时间
• IPs-LE — 提取所有 IP 地址、CIDR 网段和 MAC 地址，统一格式并按范围分类
• URLs-LE — 提取代码库中的所有 URL，并给出协议和确切位置
• Paths-LE — 提取代码库中的所有文件路径，并说明它们是否仍指向实际内容
• Colors-LE — 提取代码库中的所有颜色，并指出哪些颜色不在你的调色板中

检查

• Regex-LE — 查找代码库中的所有正则表达式，并报告哪些可能导致灾难性回溯
• Versions-LE — 查找某个依赖项在仓库的各个清单文件中受到不同约束的位置
• i18n-LE — 识别项目使用的 i18n 库，然后依据该库的规则审查其目录
• Scrape-LE — 在编写抓取器之前检查网页能否抓取，并说明何时无法判断

防护

• Secrets-LE — 查找代码库中的硬编码凭据，绝不在报告中打印凭据
• EnvSync-LE — 比较目录树中的 dotenv 文件，并指出哪些文件缺少哪些键
• Unicode-LE — 查找那些隐藏含义的 Unicode 字符——双向控制字符、不可见字符、同形异义字符、混合文字系统

每款工具都独立运行：没有共享的 crate，也没有发布的核心库。若有两款工具得出相同结论，那是因为这个答案经得起两次验证。

联系 — nolindnaidoo.com · GitHub · LinkedIn

nolindnaidoo 的其他项目

Rust — pixelcoords 和 pixelactions 构成一个工作循环：pixelcoords 回答 位置，pixelactions 在那里执行操作。它们有各自的工具、各自的风格——不属于 LE 系列。

• pixelcoords — 冻结屏幕，标记区域，获取像素级精确的坐标和裁剪图像 pixelcoords.dev · crates.io · docs.rs
• pixelactions — 使用经过人工验证的坐标执行交互，并确认操作已生效 pixelactions.dev · crates.io · docs.rs

许可证

MIT © nolindnaidoo