从零开始搭建规范的typescript-react项目

从零开始搭建规范的typescript-react项目

新建TS-React项目

1. 安装create-react-app

   npm install -g create-react-app
   

2. 初始化TS-React项目

   create-react-app my-app --template typescript
   # react-scripts-ts是一系列适配器，它利用标准的create-react-app工程管道并把TypeScript混入进来。
   

3. 这样项目就创建好了，目录结构如下

   my-app/
   ├─ .gitignore
   ├─ node_modules/
   ├─ public/
   ├─ src/
   │  └─ ...
   ├─ package.json
   ├─ tsconfig.json
   └─ tslint.json
   /*
   tsconfig.json包含了工程里TypeScript特定的选项。
   tslint.json保存了要使用的代码检查器的设置，TSLint。
   package.json包含了依赖，还有一些命令的快捷方式，如测试命令，预览命令和发布应用的命令。
   public包含了静态资源如HTML页面或图片。除了index.html文件外，其它的文件都可以删除。
   src包含了TypeScript和CSS源码。index.tsx是强制使用的入口文件。
   */
   

4. 配置代码规范，我们使用的是(Eslint+prettier+husky+lint-staged+commitlint)

Eslint

1. 我们创建项目的时候已经自动帮我们下载好了eslint依赖，如果没有下载的话我们使用以下命令安装即可

npm install -g eslint // 建议全局安装
npm install eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
# eslint：javascript代码检测工具，使用espree解析器
# @typescript-eslint/parser：将 TypeScript 转换为 ESTree，使 eslint 可以识别
# @typescript-eslint/eslint-plugin：只是一个可以打开或关闭的规则列表

2. 初始化eslint，使用命令

eslint --lint

有三种可选择的方式，检查语法错误，检出语法错误和问题，检查语法错误和强制代码规范，由于我们使用prettier来配置代码规范，所以我们选择第二项，其它的按照我们自己的需求进行配置，配置完后可能会要我们下载相关规则依赖，选择yes安装即可。

3. 安装完之后我们项目的根目录下面就会多出一个.eslintrc.js文件，我们配合本地的eslint就可以使用了。

eslint yourfile.js
# 命令行会返回出现 problems 的数量和相应行数。

eslint --fix yourfile.js
# 直接修改文件

4. 我们在.eslintrc.js中配置相关规则，这时候我们的文件中可能会有一些eslint警告提示，很烦，所以我们在根目录下面定义一个.eslintignore文件，里面写的东西会被eslint忽视。

Prettier

​ Prettier 只是一个Formatting rules ，负责 enforce code style！，这也是为什么我们在选择eslint的作用时只选择第二项，因为prettier实在是太好用了。代码格式化的原理是将代码解析为抽象语法树（AST）来处理。

1. 安装prettier

npm install -g prettier  # 只安装prettier
npm install prettier eslint-config-prettier eslint-plugin-prettier
# prettier: 格式化规则程序
# eslint-config-prettier: 禁用所有和 Prettier 产生冲突的规则
# eslint-plugin-prettier: 把 Prettier 应用到 Eslint，配合 rules "prettier/prettier": "error" 实现 Eslint 提醒。实际上是把prettier变成插件，然后如果有错误就通过eslint抛出来

2. 我们也可以在项目根目录下面创建两个文件，一个配置文件和一个忽视文件。.prettierrc.js配置文件（配置文件的后缀其实也可以是.json等多种更格式，但是.js的优先级最高，具体可以上官网查看）及.prettierignore忽略文件，具体规则我们可以去prettier官网去查找，或者去npm上下载别人已经写好的代码规范，然后导入到我们的项目中去。我们这个项目初始化的过程中使用prettier默认的规则就好，暂时不去自定义相关的规范。

   

3. 使用

prettier yourfile.js
# 返回格式化后的文件内容

prettier --write yourfile.js
# 直接修改文件

4. 效果，可以看到我们不符合prettier规范的相关代码会用波浪线标记出来。

husky+lint

使用husky的好处，可以在代码提交之前执行触发.git/hooks下面的钩子函数，例如使用precommit，这样就可以在提交之前去执行一遍lint或者lint-staged,lint是会把项目的所有目录都跑一遍看有没有不符合eslint规范的，而lint-stage可以只看这一次改动的git暂存区中的代码是否符合规范。一般项目中的检查过程如下：

代码提交 --> 发现问题(远程) --> 修复问题 --> 重新提交 --> 通过检查(远程)

1. 下载husky

   npm install -D husky
   

2. 下载完之后package.json下面会多出husky这个属性，会在pre-commit这个钩子函数之前执行npm run lint这个脚本，由于这个脚本创建项目的时候并没有给我们创建好，我们自己在scripts属性中添加这个命令。

我们尝试试一下去执行git commit，看会不会执行lint脚本，这边临时解决一个问题，当我们git add .的时候，会出现很多的warning

这个问题是由于操作系统的不同导致的。CRLF, LF 是用来表示文本换行的方式。CR(Carriage Return) 代表回车，对应字符 '\r'；LF(Line Feed) 代表换行，对应字符 '\n'。由于历史原因，不同的操作系统文本使用的换行符各不相同。主流的操作系统一般使用CRLF或者LF作为其文本的换行符。其中，Windows 系统使用的是 CRLF, Unix系统(包括Linux, MacOS近些年的版本) 使用的是LF。系统间的这个差异给跨平台协作开发和跨平台运行带来很多不方便的地方。所以我们定义一个.gitattributes文件。加上下面的这些命令。（Git的gitattributes文件是一个文本文件，文件中的一行定义一个路径的若干个属性。），这里表示以这些文件结尾的文件结尾都是使用lf

回到正题，我们使用git commit试一下，发现不行（淦），找了半天，在官网的issues上找到发现是新版本（我安装的时候最新的版本是7）有问题，所以只能卸载重新安装低版本。安装完之后如果.git/hooks目录下出现了不带sample结尾的文件就成功了，这些都是husky创建的，带sample的不会执行的。再次测试，我们故意写错className,运行之后达到我们的期望了，可以很好的减少代码错误

但是这样每次提交lint都会对文件中的整个目录进行遍历，实在不好，所以我们使用lint-staged只对暂存区中的代码进行检查

husky+lint-staged

1. 下载lint-staged

npm install -D lint-staged

2. 更改husky配置

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"  // pre-commit之前执行lint-staged
    }
  },
  "lint-staged": {
    "eslint --fix --ext .js,.tsx,.jsx,.ts ./src": [
      "eslint",
      "eslint --fix --format=pretty",
      "git add"] // lint-staged会对这些文件一次执行这些操作，如果只需要eslint检查的话也可以写成"eslint"，而不需要以数组形式表现出来
  },
  
  // 不写成数组
  "lint-staged": {
  	"eslint --fix --ext .js,.tsx,.jsx,.ts ./src":"eslint"
  }
  

增加git commit提交规范

Git 提交应当书写 commit message。message 的内容怎么写都行，但如何写比较合理是一个问题。开源社区有很多相关的规范，使用最广泛的则是Angular Git Commit Guidelines 规范，并且有众多相关的工具可以检测提交是否遵循了预定义的规范。我们借助这个使用husky+commitlint实现提交规范

1. 安装

npm install --save-dev @commitlint/config-conventional @commitlint/cli
# 前提是安装了husky

2. 更改husky属性

"husky": {
	"hooks": {
	"pre-commit": "lint-staged",
	"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
	}
},

3. 根目录下面增加commitlint.config.js文件，文件内容我们写成下面这样

module.exports = {
  extends: ["@commitlint/config-conventional"],
};
// extends字段表示扩展子@commitlint/config-conventional的配置。一般扩展这个就足够了，这是利用的commitlint的配置扩展机制，可以继承其他人的配置。如果我们有需要还是可以配置自己的规则。现在没必要

然后我们提交代码的时候就要遵循规范了。随便提交就会报错

gitlab的CI/CD来规范代码

仅仅通过git的hook来执行代码的规范检测有一个问题，我们可以在git commit的时候通过–no-verify来跳过代码的规范检测。但是某些情况下，我们对于某一个重要分支，该分支上的代码必须完整通过代码的规范检测，此时我们可以使用gitlab的CI/CD。

同样在package.json中增加一个lint的npm 命令：

  "scripts": {
     "lint": "eslint src --fix --ext .ts,.tsx "
  }

然后在根目录增加.gitlab-ci.yml文件，该文件中的配置为：

stages:
  - lint

before_script:
  - git fetch --all
  - npm install 

lint:
  stage: lint
  script:
    - npm run lint
  only
    - 特定分支1
    - 特定分支2

现在我们的项目就搭建好了，之后我会继续在这个项目的基础上引进webpack+react-redux+hooks来实现一些小功能。

贴上我的代码仓库，有需要的小伙伴可以自取。gitee连接