我的博客地址
文章目录
- 项目及其技术栈介绍
- 前端: 项目初始化
- 前端: 使用Sass和Antd
- 前端: 开发体验优化
- 前端: 搭建路由和状态管理
- 前端: 支持Axios
- 前端: 打包与环境变量设置
- 前端: 团队代码规范
- 后端: 项目初始化和使用Koa相关
- 后端: 使用TypeORM和MySQL
- 部署: 使用nginx部署前端项目
- 部署: 后端部署
- 部署: 使用jenkins自动化部署
前言
该篇博客将会介绍如何增强开发体验，内容如下:
- 导入路径优化
- 开启sourcemap
- 构建加速和构建缓存
导入路径优化
这一步的主要目的是在导入文件时候可以使用简写的路径，比如下面的导入路径对比:
// 未优化
import { xxx } from '../../../../views/Test/index.tsx'
// 优化后
import { xxx } from '@views/Test'
为了测试这一效果，我们首先在
src文件夹中新建containers文件夹，然后再在里面新建views和shared文件夹，views主要用来存放业务相关的页面，而shared则是用于存放和业务有关的共用组件(注意这个shared和components是不一样的，component应该是和业务抽离的组件，并且在切换业务后也可以进行复用的组件，这样做有一个好处就是如果公司需要构建中台业务的时候可以直接将components里面的组件拿出来用)-
之后我们在
views和shared里面各新建一个组件
image.png -
然后在
index.tsx中引入他们并使用
image.png
效果
image.png -
但是此时在引用的路径上存在一个错误，说是不能以
.tsx文件结尾
image.png
但是当我们去掉.tsx的时候，又会发现文件无法引入了
image.png
原因是，webpack不知道你引入的这个index文件是什么类型的文件，当然这个问题解决起来也很简单，我们去到webpack.config.js文件中，添加resolve配置:
image.png
extension配置的意思是，当我导入文件时候如果没有标注文件后缀，那么就默认导入这几种类型的文件。
之后我们回到入口index.tsx中，将引入路径改成如下也可以正常运行:
image.png
image.png -
之后我们发现在这两个组件的引入位置中，都存在
./containers，那么如何省略这一块呢？也就是如何简写这一块的路径呢?
image.png
我们可以通过webpack的路径别名来做这件事。
首先我们应该去webpack.config.js中，同样在resolve中配置alias属性，将路径别名及其对应的路径放进去:
image.png
然后在入口index.tsx中将引入路径改成别名:
image.png
这时候项目虽然可以跑成功，但是因为TypeScript无法根据这个路径找到模块，所以报了错:
image.png
我们去到tsconfig.json中进行配置，添加如下属性，目的就是告诉TypeScript路径别名指向的模块:
image.png
回到index.tsx会发现已经不报错了
image.png
注意: 如果以后还需要添加路径别名，记得webpack.config.js和tsconfig.json都需要进行配置，下面是我的博客中的路径别名配置:
开启sourcemap
-
什么是sourcemap
sourcemap是就是资源信息图，它记载了引入模块的内容、名字等信息。
由于在现代前端开发中，使用的React，Vue等模块都属于DSl(领域自定语言)，需要webpack配合一些loader去转换成js代码，而这些js代码经过转化后很难进行定位，特别是在压缩变成一行代码后就更加无法辨认了，
比如我们在containers/views/ViewTest组件中跑一个错误出来：
image.png
然后在网页中点开来看，发现代码是这样的，这种还是没有经过压缩的简单组件:
image.png
那么出错的话如何更好的定位呢?答案是使用webpack的sourcemap功能。 -
开启sourcemap
要开启sourcemap非常简单，只需要在webpack的devtool属性中填写你需要的sourcemap类型即可:
image.png
这时候我们再点回之前的错误信息中可以发现，错误定位变得非常简单了:
image.png -
sourcemap分为很多个类型，下面附上sourcemap类型图，可以自行选取适合的类型
image.png
构建加速和构建缓存
什么是构建缓存
我们一般会使用webpack-dev-server来进行项目开发，当我们运行webpack-dev-server的时候它会在内存中进行项目的构建，但是当使用了babel之类的代码转换工具后，会对项目构建产生较大的性能影响，这是因为每一次的构建都会对代码进行重新转换。
而构建缓存就是将构建的公用代码缓存在磁盘上，这样做的效果就是第一次构建的时间花销会比不用缓存的构建大，但是在之后每次构建的时间花销都会大大减少。-
对比
我们拿一个较大的项目来看区别。
注: 左边是没有设置构建缓存，右边进行了构建缓存。
首先进行对比的是第一次构建时候的时间花销:
image.png
然后是第二次构建的时间花销:
image.png
可以看出在第二次构建的时候时间花销减少了百分之五十以上。 设置构建缓存和构建加速
在设置构建缓存之前我们首先要考虑的是那些地方需要进行设置，不出意外的话就是babel-loader，然后就是css-loader，因为这两类文件最多:
安装对应工具
在本项目中，我们使用的是cache-loader来做缓存，thread-loader来做构建加速
npm i -D cache-loader thread-loader-
配置
首先我们在build文件夹下新建loaders.js文件，然后在里面填写配置，如下图:
image.png
然后我们到build/rules/jsRules.js中加上配置:
image.png
再到build/rules/styleRules.js中加入配置:
注意这个地方有两个坑:
第一个是node-sass中自带multiple thread功能，所以threadLoader的线程必须设置为2，否则线程阻塞(不知道现在这个Bug修复没)，
第二个坑是在less-loader不要使用thread-loader，否则报错。
image.png -
效果
这时候我们重跑项目会发现新建了一个.cache-loader目录，这就表示成功配置完成:
image.png
另外，记得在根目录新建.gitignore文件，不要把缓存目录也上传到github上了
image.png
