本文介绍: 1、在代码格式化时采用Perttier规则,在代码校验使用ESLint2、遇到项目内有多个层叠配置时,采用就近原则作为高优先级3、ESLint等解决的是团队开发规范的问题,并不能解决其他诸如编码能力、代码合理性等问题, 还属于工程化中比较弱的一环。EditorConfig用来抹平编辑器差异的,比如文件编码,锁进格式等ESLint 关注于代码质量校验 和 代码格式校验,配合插件支持autoFix和错误提示,完全可插拔。

前言

       团队多人协同开发项目,困扰团队管理的一个很大的问题就是:无可避免地会出现每个开发者编码习惯不同、代码风格迥异,为了代码高可用、可维护性,需要从项目管理上尽量统一和规范代码。理想的方式需要在项目工程化方面,借助可灵活配置的工具自动化解决。

       而现在无论是开源项目还是成熟的团队项目,根目录下出现了越来越多的配置文件,这是前端项目在快速演变、逐渐完善健壮的一种表现,那面对这些配置文件,如果是一脸懵的状态,傻傻分不清楚不太行。

     本篇文章便来介绍跟编码风格、代码规范相关的几个场景配置功能

     ESLint、Prettier、EditorConfig

     借助于EditorConfig+Prettier+ESLint 的组合,项目中通过统一约定配置可以在团队成员在代码开发过程中就检查、约束、美化代码,统一编码风格;且可以省去很多的沟通成本,提前暴露代码缺陷,减少后期二次修改代码的风险。

EditorConfig

EditorConfig包含的内容比较少,主要是配置我们的编辑器编写代码时的简单规则,不足以满足项目更多需求;

ESLint

ESLint 是一个在 JavaScript 代码中通过规则模式匹配作代码识别和报告的插件化的检测工具,它的目的是保证代码规范的一致性和及时发现代码问题、提前避免错误发生。
ESLint 的关注点是代码质量,检查代码风格并且会提示不符合风格规范的代码。除此之外 ESLint 也具有一部分代码格式化的功能

Lint发展历程

ESLint最初是由Nicholas C. Zakas ( JavaScript 高级程序设计 作者)于2013年6月创建开源项目。它的目标是提供一个插件化的javascript代码检测工具

JavaScript发展历程中出现的Lint工具:JSLint->JSHint->ESLint/TSLint;

JSLint是最早出现的 Lint 工具,不支持灵活拓展及配置,必须接受它所有规则;JSHint 在 JSLint 的基础上提供了一定的配置项,给了开发者较大的自由,但无法添加自定义规则;

Zakas创建ESLint的初衷就是觉得当时的JSHint存在局限性,无法添加自定义规则。

ES6的出现后则让ESLint迅速大火。因为ES6新增了很多语法,JSHint 短期内无法提供支持,而 ESLint 只需要有合适的解析器以及拓展校验规则 就能够进行 Lint 检查。此时babel就为兼容ESLint开发了 babeleslint解析器,提供支持的同时也让ESLint成为最快支持 ES6 语法的 Lint 工具。

关于TSLint(已停止维护)

但自2019 年 1 月起,根据 TSLint 的官方声明,TSLint 正在慢慢被废弃,并会逐步迁移到 ESLint作为代码检查的工具。至于停止维护的原因:一是ESLint社区更活跃、越来越完善,且社区对ESLint的拥护声浪越来越高,相反TSLint则完善度不够;二是在持续迭代、支持新特性的过程中发现TSLint 的规则运作方式存在架构性的性能问题,相反的 ESLint 则具有更高效能的架构

支持的配置文件格式

JavaScript- 使用 .eslintrc.js 然后输出一个配置对象

YAML – 使用 .eslintrc.yaml 或 .eslintrc.yml 去定义配置的结构。

JSON – 使用 .eslintrc.json 去定义配置的结构,ESLint 的 JSON 文件允许 JavaScript 风格的注释。

(弃用) – 使用 .eslintrc,可以使 JSON 也可以是 YAML。

package.json – 在 package.json 里创建一个 eslintConfig属性,在那里定义你的配置。如果同一个目录下有多个配置文件,ESLint 只会使用一个。优先级顺序如下:

.eslintrc.js

.eslintrc.yaml

.eslintrc.yml

.eslintrc.json

.eslintrc

package.json

遇到项目内有多个层叠配置时,采用就近原则作为高优先级

Prettier

Prettier是一个诞生于2016年就迅速流行起来的专注于代码格式化的工具。出道即巅峰。Prettier只关注格式化,并不具有lint检查语法等能力。它通过解析代码并匹配自己的一套规则,来强制执行一致的代码展示格式。它在美化代码方面有很大的优势,配合ESLint可以对ESLint格式化基础上做一个很好的补充。

VSCode内置的代码格式化工具可以指定为由Prettier接管,此时右下角会显示为Prettier。可以自行配置格式化触发机制:换行时格式化、保存文件时格式化、还是自行快捷键触发;

配置项

在VSCode 首选项-设置-扩展.settings.json中更改通用配置;

在具体项目根目录设置.prettierrc.js单独配置;

module.exports = {
  // 一行最多 120 字符
  printWidth: 120,
  // 使用 2 个空格缩进
  tabWidth: 2,
  // 不使用缩进符,而使用空格
  useTabs: false,
  // 行尾需要有分号
  semi: false,
  // 使用单引号
  singleQuote: true,
  // 对象key 仅在必要时用引号
  quoteProps: 'as-needed',
  // jsx 不使用单引号,而使用双引号
  jsxSingleQuote: false,
  // 末尾需要有逗号
  trailingComma: 'none',
  // 大括号内的首尾需要空格
  bracketSpacing: true,
  // jsx 标签的反尖括号需要换行
  jsxBracketSameLine: false,
  // 箭头函数,只有一个参数的时候,也需要括号
  arrowParens: 'always',
  // 每个文件格式化的范围是文件的全部内容
  rangeStart: 0,
  rangeEnd: Infinity,
  // 不需要写文件开头的 @prettier
  requirePragma: false,
  // 不需要自动文件开头插入 @prettier
  insertPragma: false,
  // 使用默认的折行标准
  proseWrap: 'preserve',
  // 根据显示样式决定 html 要不要折行
  htmlWhitespaceSensitivity: 'css',
  // vue 文件中的 script 和 style 内不用缩进
  vueIndentScriptAndStyle: false,
  // 换行符使用 lf
  endOfLine: 'lf',
  // 格式化嵌入的内容
  embeddedLanguageFormatting: 'auto',
  // html, vue, jsx 中每个属性占一行
  singleAttributePerLine: false
}

格式化的生效策略同样是就近原则,一步步匹配目标文件最近父目录配置文件,越近优先级越高。

总结

1、在代码格式化时采用Perttier规则,在代码校验时使用ESLint

2、遇到项目内有多个层叠配置时,采用就近原则作为高优先级

3、ESLint等解决的是团队开发规范的问题,并不能解决其他诸如编码能力、代码合理性等问题, 还属于工程化中比较弱的一环。

  • EditorConfig 是用来抹平编辑器差异的,比如文件编码,锁进格式等
  • ESLint 关注于代码质量校验 和 代码格式校验,配合插件支持autoFix和错误提示,完全可插拔
  • Prettier Prettier只关注代码格式,也支持自动修复,规则和ESLint不同

Q&A

如何解决Prettier与ESLint的配置冲突问题?

解决方式一:要么修改 eslintrc,要么修改 prettierrc 配置,让它们配置保持一致;

解决方式二:禁用 ESLint中和Prettier配置有冲突的规则;再使用 Prettier 来替代 ESLint 的格式化功能

原文地址:https://blog.csdn.net/yxf15732625262/article/details/134191665

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

如若转载,请注明出处:http://www.7code.cn/show_1473.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注