解析 none-ls.nvim 中格式化功能失效问题

问题背景

在 none-ls.nvim 项目中，用户报告了一个关于代码格式化功能失效的问题。具体表现为当使用 stylua 或 prettier 等格式化工具时，虽然工具本身输出了正确的格式化结果，但 none-ls.nvim 未能正确应用这些更改。

问题现象

用户提供了一个最小复现案例：

1. 创建一个简单的 Lua 文件，内容为 return {} 的空表结构
2. 执行 vim.lsp.buf.format() 命令
3. 预期结果应该是文件被格式化为 return {} 的紧凑形式
4. 实际结果却是格式化未被应用

技术分析

通过查看调试日志，发现了一个关键现象：

• stylua 工具确实执行并输出了正确的格式化结果
• 但这些结果被记录在了错误输出（stderr）而非标准输出（stdout）中
• none-ls.nvim 的生成器工厂将 stderr 内容标记为错误输出而忽略了它

深入代码分析发现，问题源于 check_exit_code.lua 文件中缺少一个 return 语句。具体来说：

• 在验证退出码时，成功情况下应该返回 true
• 但由于缺少 return 语句，函数实际上返回了 nil
• 这导致格式化结果被错误地判定为失败

解决方案

项目维护者迅速定位并修复了这个问题，修复内容包括：

1. 在 check_exit_code.lua 中补全了缺失的 return 语句
2. 确保格式化工具的成功输出能被正确处理

经验总结

这个案例展示了几个重要的开发经验：

1. 边界条件测试的重要性：即使是简单的格式化工具集成，也需要测试各种边界情况
2. 错误处理的严谨性：对子进程的退出码和输出流的处理需要特别小心
3. 调试信息的价值：详细的调试日志对于快速定位问题至关重要

对用户的建议

对于使用 none-ls.nvim 的开发者，建议：

1. 保持插件版本更新，及时获取修复
2. 遇到类似问题时，首先检查 :NullLsLog 输出的调试信息
3. 对于格式化问题，可以尝试直接运行格式化工具验证其行为

这个问题虽然看似简单，但揭示了 LSP 客户端与外部工具集成时的一些微妙之处，值得开发者们借鉴。