EditConfig约束(代码格式校验)

3.1、背景

• 项目中经常使用不同的编辑器，例如vscode、webstorm、ATOM、Sublime等，在每个编辑器中都存在默认的编辑器风格和约束，每个人也有可能会根据个人的风格去创建、修改，但是这样是不利于项目团队的维护的，在感官和视觉上造成阅读困难。为此需要找到一种可以适配约束不同编辑器的开发方式进行约束，既满足个人的开发编辑器的习惯，又可以让团队的风格趋同

3.2、解决方案

• 使用EditorConfig，EditorConfig是用于定义编码样式的文件格式和文本编辑器插件集合组成，这些插件使编辑器能够读取文件格式并遵守定义的样式，有助于为不同 IDE 编辑器上处理同一项目的多个开发人员维护一致的编码风格。
• editconfig官网：EditorConfig

3.3、安装步骤

• 首先可以去官网查看是否需要安装，有的插件自带此功能。
• 常用编辑器1：vsCode

• • 打开vsCode
  • 搜索插件 EditorConfig for VS Code
  • 点击安装并重启

• 常用编辑器2： webStrome

• • 打开webStrome
  • 点击 File > settings > Plugins
  • 在Marketplace中搜索EditorConfig
  • 点击安装

• 创建 EditorConfig

• • 根目录下新建.editorconfig文件

# EditorConfig is awesome: https://EditorConfig.org

root = true                         # 根目录的配置文件

[*]                                 # 所有文件生效
indent_style = space                # 空格缩进,可选"space"、"tab"
indent_size = 2                     # 缩进空格为2个
end_of_line = lf                    # 结尾换行符，可选"lf"、"cr"、"crlf"
charset = utf-8                     # 文件编码是 utf-8
trim_trailing_whitespace = true     # 不保留行末的空格
insert_final_newline = true         # 文件末尾添加一个空行
curly_bracket_next_line = false     # 大括号不另起一行
spaces_around_operators = true      # 运算符两边都有空格
indent_brace_style = 1tbs           # 条件语句格式是 1tbs

[*.md]                              # 对markdown文件生效            
trim_trailing_whitespace = false    # 不保留行末的空格

[package.json]                      # 对 package.json 生效
indent_size = 2                     # 使用2个空格缩进

[Makefile]                          # 对 Makefile 生效
indent_style = tab                  # 空格缩进为 tab

3.4、运行机制

• 当打开一个文件时，EditorConfig插件会在打开文件的目录和其每一级父目录查找.editorconfig文件，直到有一个配置文件root=true
• EditorConfig的配置文件是从上往下读取的并且最近的EditorConfig配置文件会被最先读取. 匹配EditorConfig配置文件中的配置项会按照读取顺序被应用, 所以最近的配置文件中的配置项拥有优先权
• 如果.editorconfig文件没有进行某些配置，则使用编辑器默认的设置

3.5、 EditorConfig、Eslint、Prettier的区别

• EditorConfig EditorConfig 是用来抹平编辑器差异的。帮助使用不同IDE开发同一个项目的开发者，维持固定统一的代码风格
• ESLint 关注于代码质量校验 和 代码格式校验，配合插件支持autoFix和错误提示，完全可插拔。eslint的关注点是代码质量和代码格式，何为代码质量？如未使用变量、三等号、全局变量声明等问题。何为代码格式？如单行代码太长、tab的长度、空格、逗号，单双引号等问题。对于质量和格式问题，eslint可以给出错误或警告提示，也可以自动修复，autofix。eslint的原则是一切皆可配，没有什么必须要禁止，或必须要使用的规则，如果有，这些规则应该从语言本身就限制掉,灵活是有代价的，虽然每个规则都可配，但要配置那么多规则也是及其繁琐的，因此有人提供了一些preset，也就是预设规则，通常由一些最佳实践集成而来
• Prettier只关注代码格式，也支持自动修复，规则和ESLint不同Prettier只关注代码格式。在之前很流行，尤其是在eslint还不支持autoFix时，它即可单独使用，也可以配合编辑器使用，不如Eslint。

有一部分是整理的别人笔记，但是时间久了。。。找不到原链接了