@typescript-eslint两类非空断言规则冲突，该如何处理？

这俩规则同时出现在plugin:@typescript-eslint/all配置里确实会造成矛盾——前者要求用!非空断言替代as string这类类型断言，后者直接禁止使用!运算符。可以从以下几个方向解决：

1. 针对性禁用冲突规则 #

根据团队的代码规范选择保留其中一条：

• 如果允许使用非空断言，只是希望统一风格：在ESLint配置中禁用no-non-null-assertion，保留non-nullable-type-assertion-style，这样就可以合规使用!来做非空断言。
• 如果团队禁止任何非空断言：禁用non-nullable-type-assertion-style，保留no-non-null-assertion，此时需要用提前判空的方式替代断言，比如：

  const id = getSyncValue(this.id$);
  if (id === null) {
    // 根据业务场景抛出错误或处理空值，确保后续id类型为string
    throw new Error('id 在此上下文不应为null');
  }
  const payload: Payload = { id, changes: { ... } };
  

• 也可以在特定代码块临时禁用规则，用注释解决局部冲突：

  // eslint-disable-next-line no-non-null-assertion
  id: getSyncValue(this.id$)!,
  

  或者

  // eslint-disable-next-line non-nullable-type-assertion-style
  id: getSyncValue(this.id$) as string,
  

2. 用更安全的方式替代断言（推荐） #

如果不想依赖断言或规则禁用，可通过类型守卫让TypeScript自动推导类型：

// 定义通用非空类型守卫
function isNotNull<T>(value: T | null): value is T {
  return value !== null;
}

const id = getSyncValue(this.id$);
// 判空后TypeScript会自动识别id为string类型
if (!isNotNull(id)) {
  throw new Error('意外的null值：id');
}
const payload: Payload = { id, changes: { ... } };

这种方式既符合类型安全要求，也不会触发任何ESLint规则冲突。

3. 替换plugin:@typescript-eslint/all配置 #

all配置会启用所有规则，但很多规则在实际项目中存在冗余或冲突，建议改用plugin:@typescript-eslint/recommended作为基础配置，再根据团队需求选择性开启额外规则，从根源上避免这类冲突。

内容的提问来源于stack exchange，提问作者fservantdev