最近在学习React hooks和TS的技术栈，跟着视频课程做完之后决定自己的搭建一个项目练练手，奈何在做基本配置时就难住了我！相信这是很多同学的现状——动手和记忆的速度跟不上视频播放速度，下面我们就通过这篇文章，详细地阐述下如何从零开始配置一个完整的React+TS项目。
大纲：
初始化项目
安装开发依赖
搭建mock环境
一、初始化项目
1.运行cmd，执行
create-react-app 项目名 --template typescript
没有安装create-react-app的同学，请使用npx命令
npx create-react-app 项目名 --template typescript
2.用IDE打开项目文件
可以看到create-react-app已经很贴心的帮我们把依赖安装好了，并且已经提交了第一个git commit。
3.删除CLI中你所不需要的文件
因为我是全面学习的目的，所以目录下所有的文件我都保留了下来，包括一些静态资源和测试文件。具体的文件目录结构和介绍，请自行Goole。
4.tsconfig.json
修改baseUrl：
"baseUrl": "./src"
其他的配置项，依据具体项目修改配置
5.安装开发依赖
很多人搞不清开发环境和生产环境的区别，导致在安装依赖时分不清到底应该使用哪个命令后缀（--save-dev和-dev），其实它们的区别很简单。通俗来讲，开发环境就是我们程序员平时写代码和测试的环境，生产环境就是打包之后在线运行的环境，所以在安装项目依赖时，我们应该尽量地区别这个包到底是不是仅仅在我们开发过程是会使用到，还是只是生产环境所依赖的。如果只是开发环境所依赖的，那么请使用--save-dev，如果是生产环境所依赖的，我们就使用-dev。
我们这里所讲的是开发依赖，所以请大家统一使用：
npm i npm-pakage --save-dev
不知道你是否有过以下这种经历：
你的领导指派了几个新的Bug让你修复，于是你从仓库就把有问题的项目克隆了下来，你满心欢喜地准备开始大展拳脚，然后你打开了你即将要维护的文件开始阅读历史代码，你在凌乱的代码中好不容易找到了入口事件，片刻之后你修复了Bug，自然而然地用你本地IDE的快捷键格式化了这份代码。git add，git commit， git push，git merge，一通操作之后，你把代码提交到了你的领导那里review。结果，你的领导龙颜大怒，质问你道：“我让你改个Bug，一个文件你给我搞300多处change？你让我怎么看！”，你看了一眼历史记录，试图解释道：“领导是这样的，这个Bug修复我只用了几行代码，但是我看到这份代码里有很多不规范的地方，我就格式化了一下，这样的话更方便您的阅读。”接着，领导语重心长地想你传授“技巧”：“历史代码里虽然有很多不规范的地方，但是你不要随便去修改它，它存在自有它存在的意义，你把你代码改好了提交上来，其他的不用管就行。”
即使这样，我仍然认为。不谈规模大小，代码开发规范是一个开发人员，甚至一个公司开发部门都需要共同遵守的规范，一个人一个风格和规范，不仅会增加项目维护和人员之间沟通的成本，而且对我这么一个有代码洁癖的人是一件极其难以容忍的事情，而且在么一个充满轮子的时代，还能找不到一个合适的工具来帮我们承担管理代码规范和减轻规范代码工作量？唉，聪明人不少，其中懒人居多。
5.1 安装prettier
说了这么多废话，我们引出了开发依赖中浓墨重彩的一笔——perriter，一个代码风格的统一管理工具，能够帮助我们抹平不同平台，不同IDE之间的代码风格差异，能够让整个团队统一代码风格。
prettier官网，安装prettier：
npm i prettier --save-dev
为了和脚手架自带的eslint兼容配置，我们还需要安装 eslint-config-prettier，它可以自动的合并eslint和prettier中冲突的配置项：
npm i eslint-config-prettier --save-dev
如果有特殊的配置需求，请参阅 preitter options。
5.2 安装lint-staged
lint-staged可以帮我们过滤出git暂存区里的文件，并运行一些lint检查或者单元测试的任务。搭配husky，可以在git提交时对我们的即将提交的文件进行代码风格检查，commit message检查等，安装lint-staged：
npm i lint-staged --save-dev
安装完成后，我们在pakage.json文件中针对我们需要格式化的目录和文件夹写入以下配置：
"lint-staged": {
"*.{js,css,md,ts,tsx}": "prettier --write"
}
5.3 安装commitlint
commitlint是一个commit message检查工具，方便我们规范git提交备注信息。安装：
npm i @commitlint @commitlint/config-conventional --save-dev
config-conventional是一个配置文件，它涵盖了我们git提交的大部分场景，默认提供以下类型枚举：
feat：新功能（feature）
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
安装完成之后，我们还需要在commitlint的配置文件(commitlint.config.js)中添加以下代码：
module.exports = {extends: ['@commitlint/config-conventional']}
或者直接通过命令生成：
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
自定义配置，请参阅commitlint/docs/reference-rules.md
5.4 安装husky
在我们提交代码时，可以通过命令单独运行prettier和commitlint检查的，但是我们还有一个更好的自动化的工具——husk。husky是一个Git Hook工具，它可以让我们在git生命周期中执行自己的脚本，这里我们主要是用到了
“pre-commit”这个git hook，在代码统一提交之前我们可以全面地整理文件中的代码风格并检查commit message，将不符合规范的部分统一风格。安装husky：
npm i husky --save-dev
然后执行：
husky install
此时我们的项目根目录下会生成“./husky”目录，最后我们就可以将生命周期对应的命令写入到这个文件夹下了。
对于这里的配置要求，我们只需要执行一下两条命令：
针对peritter执行：
husky add .husky/pre-commit "npm lint-staged"
针对commitlint执行：
husky add .husky/commit-msg "npm commitlint --edit"
6.搭建mock环境
这里我推荐mock方案中比较优秀的以为——json-server，按照原作者所说，json-server可以在30s搭建出一个mock环境（使用之后，确实如此）。其使用restful的api风格，不仅可以mock数据，也可以以json文件的方式将mock的数据持久化的保存在本地。安装json-server：
npm i json-server --save-dev
然后我们在我们的项目根目录下建立“json-server-mock”文件夹，在这个文件夹下面建立一个“db.json”文件，json-server会自动根据我们db.json文件中第一级的key名生成对应的restful风格的api，例如：
{
users：[]
}
运行：
json-server --watch ./__json-server__/db.json --port 4000
json-server就会根据db.json文件生成一个名为“http://localhost：4000/users”的接口：
GET /posts
GET /posts/1
POST /posts
PUT /posts/1
PATCH /posts/1
DELETE /posts/1
为了方便启动，我们可以建立一个json-server的快捷启动命令，下次就可以使用“npm json-server”快速启动啦。
npm set-script json-server "json-server --watch ./__json-server__/db.json --port 4000"
至此，一个React+TS的项目的配置基本就初始化完成了（好像和TS没啥关系）。这个配置流程也适合大多数的前端项目，旨在记录和学习，如有错误欢迎大家指正。
