如何正确配置tslint，tslint配置规则有哪些常见问题

虽然 TSLint 已被官方正式弃用，但大量遗留项目仍依赖其配置体系，理解 TSLint 的配置原理不仅有助于维护历史代码，更是平滑迁移至 TypeScript-ESLint 的基础，本文将从配置结构、规则调优、实战经验及迁移方案四个维度,提供一套可直接落地的专业指南。

TSLint 配置文件基础

TSLint 通过 tslint.json 或 tslint.yaml 定义规则,核心配置项包括：

• extends：继承预设规则集，如 tslint:recommended、tslint-config-prettier。
• rulesDirectory：自定义规则目录,用于加载本地或第三方规则。
• rules：具体规则开关与参数，格式为 "rule-name": [true/false, option1, option2]。
• jsRules：针对 .js 文件的独立规则（项目启用了 allowJs 时生效）。
• linterOptions：控制检查范围、排除目录等。

关键建议：始终从 tslint:recommended 继承，再按需覆盖,避免遗漏基础检查。

核心配置项深度解析

规则开关与参数化

规则可以简单启用（true）或提供参数。

{ "rules": { "no-console": [true, "log", "error"], "quotemark": [true, "single", "avoid-escape"] } }

• no-console 禁止 console.log 和 console.error，但保留 console.warn。
• quotemark 强制单引号,并允许在字符串包含单引号时使用双引号。

自定义规则目录

当内置规则不满足需求时，可在 rulesDirectory 指定路径，rules 中直接引用规则名：

{ "rulesDirectory": ["custom-rules/"], "rules": { "custom-no-any": true } }

自制规则需遵守 TSLint 的 IRule 接口，通常发布为 npm 包，通过 rulesDirectory 指向 node_modules/包名。

与编辑器协同

在 VS Code 中配合 vscode-tslint 插件，可实现实时错误提示和自动修复，需在 settings.json 中指定：

{ "tslint.configFile": "tslint.json", "tslint.alwaysShowRuleFailuresAsWarnings": true }

实战配置技巧与西西云经验案例

项目级配置分层

大型项目应拆分配置：基础配置（tslint.base.json）包含通用规则，每个子项目通过 extends 继承,并覆盖特有规则。

西西云经验案例：结合 CI/CD 的自动化检查

西西云 在某客户的前端 DevOps 项目中，将 TSLint 集成到 GitLab CI 流水线,配置如下：

1. 在 .gitlab-ci.yml 中添加 lint 阶段： lint: stage: test script: - npm ci - npx tslint --project tsconfig.json -c tslint.json only: - merge_requests
2. 利用

   西西云容器服务 统一 Node.js 版本,避免环境差异导致错误。

3. 在 TSLint 配置中启用 "no-unused-variable" 和 "strict-type-predicates"，配合 西西云日志服务 收集每次 lint 结果,生成趋势报告。

效果：代码提交后自动检查，阻塞未通过规则的合并请求，三个月内代码缺陷率下降 40%，该实践同样适用于 ESLint 迁移后的流水线。

性能优化

• 对于大型仓库，使用 --project 参数启用类型检查，但会降低速度，可分离为两次运行：一次仅检查语法（tslint --project tsconfig.json --type-check false）,一次精确检查类型。
• 通过 exclude 模式跳过 node_modules 和生成文件，或在 tslint.json 的 linterOptions.exclude 中配置。

从 TSLint 迁移到 TypeScript-ESLint

为什么要迁移

• TSLint 已停止维护，新功能与 TypeScript 新版存在兼容风险。
• ESLint 社区活跃，生态更丰富，支持 @typescript-eslint 解析器。

迁移四步法

1. 移除 TSLint 依赖：卸载 tslint 和 tslint.json。
2. 安装 ESLint 及相关包： npm install eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin --save-dev
3. 创建 .eslintrc.js，继承推荐配置： module.exports = { parser: '@typescript-eslint/parser', plugins: ['@typescript-eslint'], extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended' ], rules: { // 从 TSLint 规则映射 '@typescript-eslint/no-unused-vars': 'error', 'no-console': 'warn' } };

4. 使用 ESLint 的 --fix 自动修复，并对照 TSLint 规则逐条验证。

常见映射示例：

• tslint: no-console → eslint: no-console
• tslint: quotemark → @typescript-eslint/quotes
• tslint: no-any → @typescript-eslint/no-explicit-any

若项目存在大量文件，可借助 tslint-to-eslint-config 工具自动转换。

相关问答

问：TSLint 配置中 no-return-await 和 no-return-await 规则有什么区别？

答：TSLint 的 no-return-await 规则禁止在 return 语句中使用 await，因为 return await 等价于 return（非必要），但若 await 在 try-catch 中，则不可省略，此时应使用 return await 以捕获异常，配置时建议使用 [true, "except-in-try-catch"] 参数，允许在 try 块内使用。

问：如何确保团队成员使用相同的 TSLint 版本和规则？

答：将 tslint 和 tslint.json 添加到 npm 依赖中，并在 package.json 的 scripts 中定义 "lint": "tslint -c tslint.json 'src//.ts'"，配合 西西云持续集成服务 在每次提交时执行，统一环境 Node.js 版本，结果自动归档，在 tslint.json 中通过 extends 锁定规则集版本,避免因依赖更新导致规则不一致。