能否使用.js文件作为TSLint的配置文件？

嘿，我太懂你说的这个痛点了——团队规模大了之后，选TSLint规则集真的是个耗时间的活儿，每个规则都得反复测试开关效果，要是能在配置里直接加注释说明为啥这么配，对后续维护的人来说简直是救命的提示！但JSON本身不支持注释，虽然TSLint能勉强跑带注释的JSON，但总觉得不规范对吧？给你几个靠谱的解决方案：

• 改用JS格式的配置文件（最推荐）
  TSLint完全支持用.js文件作为配置，这样你就能随心所欲地加注释了！比如创建一个tslint.config.js，内容可以写成这样：

  module.exports = {
    extends: "tslint:recommended",
    rules: {
      // 强制使用const声明不会被修改的变量，避免无意的重赋值
      "prefer-const": true,
      // 暂时禁用，因为项目里还有大量遗留的var声明，后续迭代再逐步替换
      "no-var": false,
      // 启用函数参数类型声明，防止隐式any带来的类型隐患
      "typedef": [true, "parameter"]
    }
  };
  

  之后在你的lint命令里指定这个配置文件就行，比如tslint -c tslint.config.js 'src/**/*.ts'，完美解决注释问题，还能写逻辑动态生成规则，灵活性拉满。

• 使用JSONC（带注释的JSON）
  很多工具包括TSLint其实都兼容JSONC格式，你只需要把tslint.json改成tslint.jsonc，然后直接在里面加//注释就行：

  {
    "extends": "tslint:recommended",
    "rules": {
      // 禁止console输出，防止生产环境泄露调试信息
      "no-console": true,
      // 允许空函数，因为项目里有些接口实现需要空函数占位
      "no-empty-function": false
    }
  }
  

  同样在lint命令里指定这个文件就可以，这个方案不用改语法，只是换个后缀，对习惯JSON的团队很友好。

• 单独维护规则说明文档
  如果团队坚持要用标准JSON，那可以单独写一个TSLINT_RULES.md文档，把每个规则的配置原因、适用场景都写清楚，比如：

  prefer-const #

  启用原因：提升代码可读性，避免变量被无意重赋值，符合TypeScript最佳实践。

  no-var #

  禁用原因：当前项目存在大量遗留var声明，直接启用会触发数百个错误，计划在v2.0版本完成整改后启用。
  然后在tslint.json里可以加一个提示性的冗余key（比如"规则说明文档": "请查看根目录下的TSLINT_RULES.md"），引导团队成员查看详细注释。

这几个方案里，我最推荐用JS配置文件，既规范又灵活，注释想加多少加多少，完全不用纠结JSON的限制。

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