Conform-to-valibot 项目中 nullish 字段默认值问题解析

问题背景

在表单验证库 Conform-to-valibot 的使用过程中，开发者发现了一个关于 nullish 字段默认值处理的异常情况。具体表现为：当使用 parseWithValibot 方法配合包含 nullish() 和默认值的 Valibot 模式时，验证结果与直接使用 Valibot 验证的结果不一致。

问题现象

开发者提供了一个测试用例，展示了三种不同的输入情况：

1. 空对象 {}
2. 包含空数组的对象 { ticketSpecs: [] }
3. 包含 null 值的对象 { ticketSpecs: null }

测试期望这些输入都能通过验证，因为 schema 中已经为 ticketSpecs 字段定义了默认值 []。然而实际测试中，parseWithValibot 方法对这些输入的验证却失败了。

技术分析

问题的根源在于 Conform-to-valibot 内部实现机制。为了处理表单数据中的空字符串转换，库内部使用了 Valibot 的 pipe 和 transform 函数，这无意中改变了原始 schema 的行为。

具体来说，Conform-to-valibot 在内部将 schema 转换为：

v.pipe(
  v.unknown(),
  v.nullish(
    v.array(v.number()),
    []
  )
)

这种转换引入了一个关键变化：

1. 原始 schema 直接使用 nullish()，允许字段完全不存在
2. 转换后的 schema 通过 pipe(unknown())，隐式要求字段必须存在某个值

这种差异导致了验证行为的不一致，使得原本应该有效的空对象输入 {} 无法通过验证。

解决方案

项目维护者已经识别并修复了这个问题。修复的核心思路是：

1. 避免在转换过程中不必要地引入 unknown 模式
2. 确保 nullish 字段的默认值处理逻辑与 Valibot 原生行为保持一致

对于急需使用修复版本的用户，维护者提供了临时解决方案，可以通过直接安装特定构建版本来获取修复。

技术启示

这个问题为我们提供了几个重要的技术启示：

1. schema 转换的风险：在对验证模式进行转换或包装时，必须谨慎处理，避免无意中改变原始模式的语义。

2. 默认值处理的一致性：表单验证库应该尽可能保持与底层验证库（这里是 Valibot）的行为一致性，特别是在默认值处理方面。

3. 测试覆盖的重要性：这个案例展示了全面的测试用例（包括各种边界情况）对于发现潜在问题的重要性。

总结

Conform-to-valibot 项目中的这个 nullish 字段默认值问题，展示了表单验证库实现中的一些微妙之处。通过分析这个问题，我们不仅理解了特定 bug 的成因，也学习到了在构建类似库时需要注意的设计原则。对于开发者来说，了解这些底层机制有助于更好地使用这些工具，并在遇到类似问题时能够快速定位原因。