eslint-plugin-react 7.36.0版本中jsx-no-literals规则崩溃问题分析

在最新发布的eslint-plugin-react 7.36.0版本中，开发者报告了一个关于jsx-no-literals规则的严重问题。该问题会导致ESLint在处理某些JSX属性时抛出类型错误，影响开发者的正常使用。

问题现象

当开发者使用jsx-no-literals规则检查包含特定JSX属性的代码时，ESLint会抛出"TypeError: Cannot read properties of null (reading 'type')"错误。这个问题特别容易在检查布尔类型的JSX属性时触发，例如：

<LayoutComponent
  entity={entity}
  fullWidth
  page="annotation-history"
  title={l('Annotation history')}
>

在上述代码中，当检查到fullWidth这个布尔属性时，规则会崩溃。

问题根源

通过分析源码变更，我们发现这个问题源于b8217ed提交中对isLiteralString和isStringLiteral函数的修改。在之前的版本中，这些函数会先检查节点和节点值是否存在（node && node.value &&），但新版本移除了这些安全检查。

具体来说，新版本直接访问node.value.type，而没有先确认node.value是否存在。当遇到布尔属性这类没有显式值的JSX属性时，node.value为null，导致尝试访问null的type属性时抛出错误。

解决方案

最简单的修复方法是在访问node.value.type前使用可选链操作符（?.）进行安全访问，改为node.value?.type。这种修改既保持了代码的简洁性，又增加了安全性。

从技术角度来看，这种修复是安全的，因为：

1. 它不会改变原有逻辑对有效节点的判断
2. 它正确处理了值为null或undefined的情况
3. 它保持了与之前版本相同的行为模式

影响范围

这个问题会影响所有使用以下情况的开发者：

1. 启用了jsx-no-literals规则
2. 代码中包含布尔类型的JSX属性
3. 升级到eslint-plugin-react 7.36.0版本

临时解决方案

在官方修复发布前，受影响的开发者可以考虑：

1. 暂时降级到7.35.0版本
2. 在配置中禁用jsx-no-literals规则
3. 或者使用patch-package等工具本地应用修复

总结

这个问题展示了静态分析工具在处理JSX各种语法变体时面临的挑战。虽然jsx-no-literals规则的主要目的是检查字符串字面量，但它需要能够安全地处理所有可能的JSX属性类型。这次的问题提醒我们，在修改核心判断逻辑时，必须考虑所有可能的输入情况，特别是边界条件。

对于规则维护者来说，这也提示我们需要为这类核心函数添加更全面的测试用例，覆盖各种JSX属性类型，包括布尔属性、展开属性等特殊情况，以避免类似的回归问题。