为了美化代码，相信不少的前端小伙伴都会在IDE中安装prettier插件，有了插件在开发过程中无论代码写得再乱最后都会被自动格式化。但是能让插件在开发过程中用得得心应手，前提是你已经在IDE中做过对应的配置。然而不同公司、不同项目格式化规范还不一样，这样每次写代码之前都得在编辑器设置好，否则干活也是事倍功半。
现在有一个全新的方式，搭配建木CI在代码推送到远程仓库时，就能自动格式化代码，有了这套流程再也不用被不同编辑器的不同插件设置所困扰。好了废话不多说，让我们一起来看看吧！

为什么要格式化前端代码

规范的代码是一个程序员基本的职业素养。首先，统一风格的代码可提高可读性、易于review，从而促进团队成员更好的协作。其次，提高代码质量，也更利于项目的维护。对于一个团队而言，代码规范十分重要，代码风格不统一会让整个团队显得极其不专业。

传统模式下，对代码风格统一管理的实践方案及其弊端

1. IDE中安装prettier插件

prettier前端代码格式化工具可能大家并不陌生，目前前端开发用到的IDE中基本上均已实现了对prettier的支持。这使得开发者可在IDE中用插件在保存文件时自动格式化代码。但如今，项目开发大部分是多人协作模式，一个团队中有多年经验的老员工，也有刚刚步入职场的新人。不同开发人员使用的IDE不一定相同，他们的prettier配置也不一样，这样格式化的代码还是不够统一。

最大的问题在于，当你打开另一个开发人员的代码时，只是单单看了一眼，但因为IDE的自动格式化功能，文件就会被按照你的prettier配置进行格式化。如果在无形中把代码推送到远程仓库，这势必会造成不必要的代码冲突。

2. 在不同的IDE中，对prettier进行相同的配置

基于上面的问题，有的小伙伴可能会想，如果统一prettier配置不就可以解决这个问题了吗？确实，按照设想只要保证不同IDE的prettier配置一致，那格式化出来的代码肯定是相同的。但是真实开发过程中，这种方式并不好实现，因为对一个习惯用vscode的人来说，他熟悉prettier在vscode中的设置，但是让他保证同样的代码在其他IDE上做到格式化出来的效果一致，这就比较困难了。虽然都使用prettier，但是在不同IDE中它们配置方式是不一样的。另外一个问题是，IDE还存在不同版本，可能上一位用webstorm的人使用prettier时比较用心，每一步该如何去配置，他都做了记录。但可能过几年后，IDE也更新了好几版，原来记录的那些操作可能在新版中压根找不到，那之前做的记录也相当于白费。

3. 团队协作中，强制用相同IDE和prettier配置

为解决上面不同IDE造成prettier格式化难以统一的问题，可能有人会疑惑，为什么我们不对开发人员的IDE进行统一，并且在团队中对IDE的prettier进行统一设置呢？虽然这样暴力一刀切的方式确实能够解决代码格式统一问题，但随意更换开发人员已经熟悉的IDE，这等同于一个战士在战场上丢掉了自己的枪。这里单单为了解决一个代码风格统一的问题，开发人员需要消耗更多时间与精力去熟悉新IDE的用法，这样一来团队开发效率也会受到影响。

用建木CI进行前端代码格式化的优势

目前建木CI已将prettier规范集成在节点中，每一个prettier节点与prettier官方维护的版本对应。这样意味着我们可以使用不同版本的prettier来保证对前端代码风格上的统一。上面提到的，在团队开发过程中，开发人员使用不同的IDE和prettier配置，造成代码风格难以统一的问题，也得到很好的规避。因为建木CI进行格式化的流程不是在开发人员的编码过程中，而是在真正将代码推送到远程仓库后，才会对它进行格式化。这样一来开发人员根本不需要在意推送到远程仓库的代码格式有多乱，甚至不需要在IDE中安装任何代码格式化的插件。因为只要再次从远程仓库拉取代码时，代码均已被格式化。有建木CI做了这些事，开发者可以将更多的精力放在其业务逻辑上。

如何搭配建木CI去实现代码格式化

拷贝下面的dsl，在建木CI上新增一个项目，流程会将代码从远程仓库拉取下来自动进行格式化。

name: prettier节点测试
description: 格式化代码

trigger:
  type: webhook
  param:
    # gitee中的webhook钩子事件
    - name: gitee_event
      type: STRING
      exp: $.header.x-gitee-event
    # 仓库项目名
    - name: project_name
      type: STRING
      exp: $.body.json.project.name
    # webhook返回的分支信息
    - name: gitee_ref
      type: STRING
      exp: $.body.json.ref
    # 提交的commit信息
    - name: commit_message
      type: STRING
      exp: $.body.json.commits[0].message
  # 条件满足时触发流程
  only: (${trigger.gitee_event} == "Push Hook" && ${trigger.commit_message} != "refactor:auto prettier code")
pipeline:
  git_clone:
    type: git_clone:1.2.1
    alias: 克隆项目
    param:
      remote_url: https://gitee.com/comyan/test-pretiier-format.git
      ref: ${trigger.gitee_ref}
  prettier_push:
    type: prettier:1.0.0-2.5.1
    alias: 格式化
    param:
      files: '["${git_clone.git_path}/*"]'
  git_push:
    type: git_push:1.0.2
    alias: push格式化代码
    param:
      remote_url: https://gitee.com/comyan/test-pretiier-format.git
      remote_branch: ${git_clone.git_branch}
      username: ((gitee.comyan_username))
      password: ((gitee.comyan_password))
      source_path: ${git_clone.git_path}
      target_dir: ${trigger.project_name}
      commit_message: 'refactor:auto prettier code'

复制链接

进入自己的仓库下，点击管理。

为项目添加webhook

本地修改一个文件，提交commit信息，将代码推送到远程仓库，代码格式化流程被自动触发。

可以看见在这次流程中，prettier节点一共为我们格式化了38个文件，并新增了一条commit信息。

在项目中prettier不能处理的文件，节点是怎样处理的呢？一起来看看prettier节点的日志信息。可以看见prettier节点，对于不能处理的文件会在日志中输出错误信息，并且它不会影响其他文件的正常格式化。

好的，本文到这儿又要跟大家说再见了。相信看完上面的内容，你已经对建木CI进行前端代码格式化有了一个初步的认识。那么接下来就让我们新建一个仓库，按照示例dsl一起动手试一试吧！