编辑器选择
在刚接触前端的时候,我使用的编辑器是sublime
。主要特点是轻量,缺点就是安装插件的时候过程比较麻烦,而且代码提示做的也不够好;后来听说webstrom
这个地表最强编辑器功能很强大,就尝试着使用这个编辑器。webstrom
给我的感觉是就功能很强大,但是很臃肿,软件包很大。实际上我用到编辑器的功能就几个,但是webstrom
给我提供了一大堆功能。主要还是webstrom
这东西太吃内存了,电脑性能支撑不起来,所以后面使用了一段时间就放弃了;后来有同学给我推荐了vscode
这个编辑器。发现这个编辑器也很轻量,而且提供了很多插件给你选择安装,最重要的是vscode
是免费的(虽然sublime也是免费的),在后来的工作中,我一直都是使用vscode
的。
代码规范
刚学前端的时候还有刚毕业出来的那一年,我其实是不怎么关注代码规范这方面的东西,基本都是代码写完了,然后在编辑器中来一个右键-格式化文档,遵循的原则就是能用能看就行了。其实中间有一段时间我是有尝试过去使用eslint
这些代码规范化的工具的,但是那时候我就是个小白,eslint
报错或者编辑器哪里提示格式不规范,我都是手动一个地方一个地方去修正的,连eslint --fix
这些命令都不知道的,更别说集成到vscode
当中了,后来就觉得太麻烦了,就没有在使用了,不过现在想想还是有点好笑,我居然会手动一个一个地方去修改那些代码不规范的问题。为什么这里要讲到代码规范呢?原因如下:
- 良好的代码规范可以减少bug的出现。比如,当初我遇见一个ie上的bug,就是使用
element-ui
的时候引入了2次Button
组件,ie上面是不允许一个对象上面出现2个同名的key的,而且ie上面的报错提示并不是很容易让人找出是什么原因,也不能具体定位到那个文件的哪一行。后来我把ie上面的报错到百度上面一查才知道是ie不允许一个对象上面出现2个同命的key的,问题根源找到了,但是是在那个文件里面,需要一个一个去找,当时这个bug花了挺久的时间才解决了。现在想想,要是当初这个项目能有个eslint
这些代码规范检查工具,这个bug应该就能很快被解决掉了。因为eslint
的规则也是不允许对象上面有2个同命key的,并且还能提示是哪个文件出现同命key的 git
提交记录。有些代码比较乱,或者有些开发者喜欢使用右键-格式化代码,将代码格式化成自己想要的格式。这就会导致git
的提交记录会被覆盖,后面再看代码就不能知道这些代码是干什么的了。打个比方,比如我在A文件
的第10行修改了一个bug,提交代码的时候写修复了xxxbug
。这里说一下,我们可以借助vscode
的插件看见代码每一行的代码提交记录的。然后另一位开发者,把A文件
拉下来,来了一个右键-格式化代码,第10行的代码被格式化了。这个时候另一位开发者把代码提交了,提交记录写的是新增xxx功能
,这个时候整个文件的每一行提交记录都是新增xxx功能
,实际上新增功能的代码就在一小段范围之内。这个时候如果其他开发者把A文件
拉下来,根本就不知道第10行的代码是修复了bug,只看见了新增xxx功能
,然后去找提交这个记录的开发者问第10行的代码是干什么用的,然后开发者就说,我没改过这里啊,我不知道啊。这样子下来,代码的提交记录就无迹可寻了,想找到当初提交代码的人问一下都不行了。- 统一规范。不同开发者可能有不同的开发习惯,有的人喜欢使用
var
,有的人喜欢用const
。这样就会导致代码的可观性非常差,一会一个样子,简直就是百花争鸣,百家齐放。
eslint
eslint
是一个检查javascript
代码规范的工具
- 安装并初始化
这里安装是基于项目来安装的,并不是全局安装的,全局安装就会使项目环境依赖于全局环境了
npm i eslint -D
npx eslint --init
npx eslint --init
命令执行完后,就会在项目的根目录下生成eslint
的配置文件
- 使用
忽略整个文件的检查,写在文件首行
/* eslint-disable */
文件开启或者禁用某些eslint
规则,写在文件首行,多个使用逗号分隔
/* eslint no-console: "error" */
或者
/* eslint-disable no-debugger, no-console */
忽略某一行的检查
// eslint-disable-next-line
或者
/* eslint-disable no-debugger, no-console */
console.log('test')
/* eslint-enable no-alert, no-console */
或者
alert('test') // eslint-disable-line no-alert
- 命令
下面三个命令是比较常用的
检查src
目录下任意目录下后缀名为js
和vue
的文件是否符合规范
eslint --ext .js,.vue ./src
修复src
目录下js
和vue
文件不符合代码规范的地方,注意有些并不能自动修复的,需要手动修复的
eslint --fix --ext .js,.vue ./src
仅仅检查和修复改变过的文件
eslint --cache --fix --ext .js,.vue ./src
- 配置
module.exports = {
// 环境
env: {
browser: true,
es2021: true
},
// 识别webpack别名,需要安装eslint-import-resolver-webpack
settings: {
'import/resolver': {
webpack: {
config: './build/webpack.base.js'
}
}
},
// 拓展,需要安装 eslint-config-prettier,eslint-plugin-prettier,eslint-config-standard,@vue/eslint-config-standard
extends: ['plugin:vue/essential', 'standard', 'plugin:prettier/recommended'],
// 解析器配置选项
parserOptions: {
// 指定es版本
ecmaVersion: 12,
// 代码支持es6,使用module
sourceType: 'module',
// 解析器,需要安装babel-eslint
parser: 'babel-eslint'
},
// 插件,需要安装eslint-plugin-vue
plugins: ['vue'],
// 规则
rules: {
'import/extensions': ['error', 'always'],
'prefer-destructuring': 'off',
'no-param-reassign': 'off',
'no-plusplus': 'off',
'consistent-return': 'off',
'import/no-extraneous-dependencies': 'off',
'no-underscore-dangle': 'off',
'import/no-named-as-default-member': 'off',
'semi': ['error', 'always'],
'node/no-callback-literal': 'off'
}
};
- 忽略文件
在项目根目录新建一个.eslintignore
文件,然后写入需要忽略检查的文件
- 规则优先级
行内配置>命令行选项>项目文件配置
stylelint
stylelint
是一个检查css
样式的规范的工具
- 安装
这里安装是基于项目来安装的,并不是全局安装的,全局安装就会使项目环境依赖于全局环境了
npm i stylelint -D
- 命令
下面2个命令是比较常用的
检查根目录下的任意目录的html,vue,css,sass,scss
文件是否符合代码规范
stylelint **/*.{
html,vue,css,sass,scss}
自动修复代码规范
stylelint **/*.{
html,vue,css,sass,scss} --fix
- 配置
在项目根目录新建.stylelintrc.js
文件。下面的配置是基于css
和scss
样式文件的,如果需要支持less
可自行进行配置
module.exports = {
// 需要安装 stylelint-config-standard,stylelint-config-recommended-scss(处理scss样式),stylelint-config-recess-order
extends: [
'stylelint-config-standard',
'stylelint-config-recommended-scss',
'stylelint-config-recess-order',
],
// 需要安装stylelint-scss,scss 拓展,增加支持 scss 语法
plugins: ['stylelint-scss'],
rules: {
'no-descending-specificity': null,
'no-empty-source': null,
},
};
- 忽略文件
在项目根目录新建一个.stylelintignore
文件,然后写入需要忽略检查的文件
- 规则优先级
行内配置>命令行选项>项目文件配置
prettier
prettier
是一个自动格式化代码的工具
- 安装
npm i prettier -D
- 使用
npx prettier --write
格式化指定文件
npx prettier --write src/index.js
- 配置文件
在项目根目录下新建.prettierrc
文件,当然也可以是.json
,.json
文件结尾
module.exports = {
printWidth: 80, //一行的字符数,如果超过会进行换行,默认为80
tabWidth: 2, //一个tab代表几个空格数,默认为80
useTabs: false, //是否使用tab进行缩进,默认为false,表示用空格进行缩减
singleQuote: false, //字符串是否使用单引号,默认为false,使用双引号
semi: true, //行位是否使用分号,默认为true
trailingComma: 'none', //是否使用尾逗号,有三个可选值"
}
统一编辑器风格
不同的编辑器的风格可能会不一样,我们要统一一下风格。在项目跟目录下新建.editorconfig
文件
[*.{
js,jsx,ts,tsx,vue}]
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
insert_final_newline = true
属性:
indent_style 设置缩进风格(tab是硬缩进,space为软缩进)
indent_size 用一个整数定义的列数来设置缩进的宽度,如果indent_style为tab,则此属性默认为tab_width
tab_width 用一个整数来设置tab缩进的列数。默认是indent_size
end_of_line 设置换行符,值为lf、cr和crlf
charset 设置编码,值为latin1、utf-8、utf-8-bom、utf-16be和utf-16le,不建议使用utf-8-bom
trim_trailing_whitespace 设为true表示会去除换行行首的任意空白字符。
insert_final_newline 设为true表示使文件以一个空白行结尾
root 表示是最顶层的配置文件,发现设为true时,才会停止查找.editorconfig文件
husky/lint-staged
husky
是一个git hook工具,可以利用husky
在git提交代码之前检查代码是否符合规范,如果不符合就不允许提交代码。
lint-staged
是一个可以让husky
只检验git工作区的文件,否则可能会导致出现很多问题
- 安装
npm i husky -D
npm i lint-staged -D
- 使用
在package.json
文件中,新增配置
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{html,vue,css,sass,scss}": [
"stylelint **/*.{html,vue,css,sass,scss} --fix"
],
"*.{js,vue}": [
"prettier --write",
"eslint --fix --ext .js,.vue ./",
"git add",
"eslint --ext .js,.vue ./"
]
},
在git commit
之前会进入工作区扫描,这里需要注意的是先执行prettier --write
,然后再执行eslint --fix --ext .js,.vue ./
,否则后面的eslint --ext .js,.vue ./
可能会执行不通过,修复完成后自动提交到工作区
Commitizen
Commitizen
是一个格式化commit message的工具
- 安装
npm install commitizen -D
- 配置
在package.json
文件,新增如下配置
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
}
上面的配置都是英文的说明,如果你想来点中文提示,可以这样配置
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
},
"types": {
"feat": {
"description": "新增功能",
"title": "feat"
},
"fix": {
"description": "bug 修复",
"title": "fix"
},
...
}
}
- 使用
使用git cz
命令代替git commit
自定义Commitizen提交说明
如果你不需要自定义提交说明,就跳过这一步,这个需要用到cz-customizable
适配器
- 安装
npm i cz-customizable -D
- 修改配置
在package.json
中修改commitizen.path
配置
"config": {
"commitizen": {
"path": "node_modules/cz-customizable"
}
}
- 新增配置文件
在项目的根目录下新建.cz.config.js
文件:
module.exports = {
types: [
{
value: 'feat', name: '新增功能'},
{
value: 'fix', name: 'bug 修复'},
{
value: 'docs', name: '文档更新'},
{
value: 'build', name: '主要目的是修改项目构建系统(例如 glup,webpack,rollup 的配置等)的提交'},
{
value: 'refactor', name: '重构代码(既没有新增功能,也没有修复 bug)'},
// ...
],
scopes: [
{
name: '模块1'},
{
name: '模块2'},
{
name: '模块3'},
{
name: '模块4'}
],
// it needs to match the value for field type. Eg.: 'fix'
/*
scopeOverrides: {
fix: [
{name: 'merge'},
{name: 'style'},
{name: 'e2eTest'},
{name: 'unitTest'}
]
},
*/
// override the messages, defaults are as follows
messages: {
type: '选择一种你的提交类型:',
scope: '选择一个scope (可选):',
// allowCustomScopes=true时使用
customScope: 'Denote the SCOPE of this change:',
subject: '短说明:\n',
body: '长说明,使用"|"换行(可选):\n',
breaking: '非兼容性说明 (可选):\n',
footer: '关联关闭的issue,例如:#31, #34(可选):\n',
confirmCommit: '确定提交说明?'
},
allowCustomScopes: true,
allowBreakingChanges: ['特性', '修复'],
// limit subject length
subjectLimit: 100
};
Commitizen校验
提交前先检验提交的信息是否规范,不规范则不可以提交
- 安装
npm i @commitlint/cli -D
npm i @commitlint/config-conventional -D
- 配置
在项目根目录下新建.commitlintrc.js
文件,写入如下配置
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [
2,
'always',
[
'build', // 主要目的是修改项目构建系统(例如 glup,webpack,rollup 的配置等)的提交
'ci', // 主要目的是修改项目继续集成流程(例如 Travis,Jenkins,GitLab CI,Circle等)的提交
'docs', // 文档更新
'examples', // 开发测试
'feat', // 新增功能
'fix', // bug 修复
'perf', // 性能优化
'refactor', // 重构代码(既没有新增功能,也没有修复 bug)
'style', // 不影响程序逻辑的代码修改(修改空白字符,补全缺失的分号等)
'test', // 新增测试用例或是更新现有测试
'revert', // 回滚某个更早之前的提交
'chore' // 不属于以上类型的其他类型(日常事务)
]
]
}
};
然后在package.json
文件中配置husky
,上面已经安装过了,直接添加配置
"husky": {
"hooks": {
"pre-commit": "lint-staged",
// 新增如下配置
"commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
}
}
vscode集成
我们可以借助vscode的插件,在保存的时候根据eslint和stylelint的配置进行自动修复。还有其他功能等。
-
在vscode的扩展中搜索
ESLint
和stylelint
,然后安装 -
在项目根目录新建
.vscode
文件夹,在该文件夹下面新建settings.json
文件,并写入如下配置
{
"eslint.validate": [
{
"language": "vue",
"autoFix": true
},
{
"language": "html",
"autoFix": true
},
{
"language": "javascript",
"autoFix": true
},
{
"language": "javascriptreact",
"autoFix": true
},
{
"language": "tyypescript",
"autoFix": true
}
],
"eslint.autoFixOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true,
"source.fixAll.stylelint": true
}
}
- git提交记录。安装
Git History Diff
可查看文件的每一行提交记录,这样就可以很方便的查找出是谁提交的记录。
webpack集成
在开发过程中,我们把那些不符合代码规范的错误显示在浏览器和控制台中,这样就可以及时的去修复代码不规范的问题,而不是在最后提交代码的时候运行eslint --fix
- 安装插件
npm i eslint-webpack-plugin stylelint-webpack-plugin -D
- 添加插件
在webpack.config.js
文件中添加以下配置
const ESLintPlugin = require('eslint-webpack-plugin');
const StylelintPlugin = require('stylelint-webpack-plugin');
module.exports ={
plugins: [new ESLintPlugin(), new StylelintPlugin()]
}
gulp集成
如果你使用的是gulp
,并且需要把那些不符合代码规范的错误显示在浏览器和控制台中,那么你需要这么做:
- 安装插件
这里需要注意的是,如果你是用的是eslint
版本大于7,需要安装gulp-eslint7
,否则就安装gulp-eslint
npm i gulp-eslint7 gulp-stylelint -D
- 配置
const {
src, dest } = require('gulp');
const eslint = require('gulp-eslint7');
const gulpStylelint = require('gulp-stylelint');
const buildCss = (srcPath, distPath) => () =>
src(srcPath)
.pipe(
gulpStylelint({
reporters: [{
formatter: 'string', console: true }]
})
)
.pipe(dest(distPath));
const buildJs = (srcPath, distPath) => () =>
src(srcPath)
.pipe(eslint())
.pipe(eslint.format())
.pipe(eslint.failAfterError())
.pipe(dest(distPath));
总结
到此,一套前端代码工作流已经搭建完毕了。需要注意的是,上面这套前端代码工作流是我搭建组件库的时候研究总结出来的,特别适合那些自己搭建一个vue
环境项目的场景。如果你是使用vuecli
脚手架,那么就应该可以省去很多流程了,毕竟脚手架已经集成了这些东西,你只需要选择对应的选项即可。如果你使用的是react
或者微信小程序,也可以参照这套工作流,就是在eslint
的配置或者stylelint
的配置上面有所差别而已。
其他
vue2组件库:https://github.com/c10342/lin-view-ui
微信小程序组件库:https://github.com/c10342/lin-wx-ui
上面2个组件库都是由我个人开发维护的,都是使用了上面那套前端代码工作流流程。有兴趣的同学可以去参考一下,或者下方留言一起学习交流。
转载:https://blog.csdn.net/vgub158/article/details/116607654