如何禁止ESLint/Prettier修改TypeScript类成员修饰符顺序？

1. 如何关闭该修饰符重排规则？ #

这个修饰符重排是Prettier的默认格式化行为（Prettier 3.x默认会将declare置于public等访问修饰符之前），目前Prettier没有提供直接关闭该行为的配置项，可行的解决方式是通过ESLint规则强制指定顺序，覆盖Prettier的修改：

在你的.eslintrc.json的rules节点中添加@typescript-eslint/member-ordering规则，有两种配置方式：

• 方式一：完全保持代码原有顺序，不自动重排（适合匹配项目旧代码风格）

"@typescript-eslint/member-ordering": [
  "error",
  {
    "members": {
      "order": "as-written"
    }
  }
]

• 方式二：精确指定成员顺序，强制访问修饰符排在declare之前

"@typescript-eslint/member-ordering": [
  "error",
  {
    "default": {
      "memberTypes": [
        // 先定义带访问修饰符的普通字段
        "public-instance-field",
        "private-instance-field",
        "protected-instance-field",
        // 再定义带访问修饰符的declare字段
        "public-declare-field",
        "private-declare-field",
        "protected-declare-field"
      ],
      "order": "alphabetical"
    }
  }
]

注意：由于你的ESLint配置继承了prettier，它会禁用部分与Prettier冲突的规则，所以需要确保@typescript-eslint/member-ordering规则在rules中被显式开启，避免被自动禁用。

2. 是否应该关闭该规则？ #

应该关闭，理由如下：

• 项目已有大量旧代码采用public declare的风格，强制修改会导致大规模代码变更，增加版本控制的冲突风险；
• 团队资深开发者明确要求保持现有风格，编码规范的一致性比工具默认规则更重要，能降低团队协作的沟通成本；
• 强行统一为Prettier的默认风格，会让旧代码维护和新代码编写产生风格割裂，不利于长期维护。

3. 是否有官方规范明确类成员修饰符的编写顺序？ #

TypeScript官方没有强制规定类成员修饰符的顺序，编译器对public declare和declare public两种写法完全兼容，不会抛出语法或语义错误。

社区层面：

• Prettier将declare设为默认前置是它自身的格式化约定，并非官方规范；
• 部分社区规范（如Airbnb TypeScript规范）会推荐访问修饰符前置，但这属于团队可选的约定，而非强制标准。

和资深开发者讨论时，可以重点围绕「团队现有代码一致性」「维护成本」展开，而非纠结于第三方规范的差异。

4. 是否需要提交新的bug报告？ #

不需要，这不是Prettier的bug，而是它有意设计的默认格式化行为。Prettier的核心设计哲学是提供单一、无配置的格式化风格，减少团队内的风格争论，因此它选择了declare在前的顺序。

如果需要自定义修饰符顺序，你可以向Prettier提交功能请求（而非bug报告），建议添加可配置的修饰符顺序选项，但能否被采纳取决于Prettier团队的规划。

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