前言
前端工程化,是面向公司的代码模块化、系统化、规范化的一个过程,在这个过程中,经过了这个过程,我们才能称得上是“正规军”。
前端工程化,有很多方面,如代码提交规范、模块化、CI/CD等,通过方方面面的约束,让代码变得可读性强、易维护等,随着项目越来越大,工程化的优势日益凸显出来。
本地代码进仓库要经历什么
Github官方给出了一些钩子函数git hooks
,使Git能在特定的重要动作发生时触发自定义脚本,分为两类,客户端和服务端的,我们常用的有pre-commit
、commit-message
等。
前端工程化的第一步,「合格的代码」。
什么样的代码是合格的,我们可以借助代码检测工具「ESlint」等,定制一套规范,例如:
module.export = {
rules: {
// ...
'react/jsx-no-target-blank': 'error',
'react/jsx-uses-react': 'error',
'react/jsx-uses-vars': 'error',
'no-unused-vars': 'error',
}
}
如代码所示,该规则约定,当有变量声明但未使用,属于no-unused-vars
,返回结果error,命令行会报错。
规则已经定好了,接下来就是自动检测代码是否合格。
然后就是几个关键的工具库
husky
是Git hooks工具,可以防止一些不好的commit和push。
lint-staged
是一个在git暂存文件上运行linters的工具。
pre-commit
钩子在键入提交信息前运行,用于检查即将提交的快照。
prettier
代码格式化工具。
在package.json
加入:
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
}
这样就完成了代码检测,可以试着运行一下git commit
命令:
![63c4d7b34870c3789ca40be260980016.png](https://i-blog.csdnimg.cn/blog_migrate/5abb345f15a72c65b459cdeb91297fb7.png)
可以看到,前边类型为error
,且后边给出了不符合eslit的no-unused-vars
规则,本次commit提交失败。
在代码符合规范之后,我们再使用prettier
对规定范围内的代码做格式化处理。先在package.json
中添加命令,规定要格式化的代码文件:
{
"scripts": {
"prettier": "prettier --config .prettierrc --write {.,components,lib,pages}/*.js {components,lib,pages}/**/*.js",
}
}
之后就可以使用命令行格式化范围内的代码。
在vscode中也可以添加prettier
插件,在保存关闭文件时就会自动格式化文件。
![7b216cebda5b947074f6282e5407e5af.png](https://i-blog.csdnimg.cn/blog_migrate/f9a908e1c7c1f11e150ea07675274b5b.png)
完成上述配置后,在执行git commit
命令后,但凡是有不符合代码,都会被禁止提交,只有将所有位置的代码修改后,才能提交,再push到仓库。
推到远程仓库后要做什么
代码被推到github后应该跑CI做自动化测试,例如「lint」、「test」、「e2e」、「codeQL」、「secure」等。
我们可以在项目中添加一个目录.github/workflows
,在该目录中添加文件,构建工作流程。
我们应该先在github action里重新运行一遍自己的项目,我们应该写这些内容:
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Use Node.js 12.x
uses: actions/setup-node@v1
with:
node-version: 12.x
- name: npm install, lint, build, and test
run: |
npm install
npm run lint
npm run build
npm start & npx wait-on http://localhost:3000 && npm run cy:run -- --config baseUrl=http://localhost:3000
env:
CI: true
CYPRESS_CI: true
这段代码将项目运行在ubuntu环境中,顺便做了个e2e测试。
然后再做codeQL:
name: "CodeQL"
on:
push:
branches: [main, ]
pull_request:
# The branches below must be a subset of the branches above
branches: [main]
schedule:
- cron: '0 10 * * 3'
jobs:
analyse:
name: Analyse
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
with:
# We must fetch at least the immediate parents so that if this is
# a pull request then we can checkout the head.
fetch-depth: 2
- run: git checkout HEAD^2
if: ${{ github.event_name == 'pull_request' }}
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v1
- name: Autobuild
uses: github/codeql-action/autobuild@v1
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v1
项目部署
我的前端项目部署在vercel.com上,授权访问github仓库,。
![396bef849f744b97338c7b596d78247e.png](https://i-blog.csdnimg.cn/blog_migrate/c5c088632acd113e1dfd42c766e2ba8c.png)
每次push代码到github时,github会发请求给vercel,携带本次push的信息,然后vercel将代码拉过去,重新运行构建部署代码。
团队工作的额外操作
对于团队工作来说,一般是自己新开一个分支,push代码到该分支。
在合并分支之前,除了应该做的测试、规范检查之外,也要做Code Review,检查代码的逻辑问题等。
在push到个人分支运行测试时,会为该分支生成一个preview的url,检查各项功能。
一切都没有问题之后,才会允许合并到主分支。
最终主分支的代码通常会手动部署。