Github Repository
本部分假设你已经对Webpack有了大概的了解,这里我们会针对笔者自己在生产环境下使用的Webpack编译脚本进行的一个总结,在介绍具体的配置方案之前笔者想先概述下该配置文件的设计的目标,或者说是笔者认为一个前端编译环境应该达成的特性,这样以后即使Webpack被淘汰了也可以利用其他的譬如JSPM之类的来完成类似的工作。
单一的配置文件:很多项目里面是把开发环境与生产环境写了两个配置文件,可能笔者比较懒吧,不喜欢这么做,因此笔者的第一个特性就是单一的配置文件,然后通过npm封装不同的编译命令传入环境变量,然后在配置文件中根据不同的环境变量进行动态响应。另外,要保证一个Boilerplate能够在最小修改的情况下应用到其他项目。
多应用入口支持:无论是单页应用还是多页应用,在Webpack中往往会把一个html文件作为一个入口。笔者在进行项目开发时,往往会需要面对多个入口,即多个HTML文件,然后这个HTML文件加载不同的JS或者CSS文件。譬如登录页面与主界面,往往可以视作两个不同的入口。Webpack原生提倡的配置方案是面向过程的,而笔者在这里是面向应用方式的封装配置。
调试时热加载:这个特性毋庸多言,不过热加载因为走得是中间服务器,同时只能支持监听一个项目,因此需要在多应用配置的情况下加上一个参数,即指定当前调试的应用。
自动化的Polyfill:这个是Webpack自带的一个特性吧,不过笔者就加以整合,主要是实现了对于ES6、React、CSS(Flexbox)等等的自动Polyfill。
资源文件的自动管理:这部分主要指从模板自动生成目标HTML文件、自动处理图片/字体等资源文件以及自动提取出CSS文件等。
文件分割与异步加载:可以将多个应用中的公共文件,譬如都引用了React类库的话,可以将这部分文件提取出来,这样前端可以减少一定的数据传输。另外的话还需要支持组件的异步加载,譬如用了React Router,那需要支持组件在需要时再加载。
在发布版本中,可能需要一些特殊的配置或者插件,譬如只有在 NODE_ENV环境变量等于 production的情况下才会有逻辑配置需要添加在配置文件中,那么在Webpack的配置文件中可以使用如下定义:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
在发布版本中,Webpack的一些配置可以被关闭,譬如:
1 2 3 4 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
开始这个小节之前,可以先看下大神的一篇文章: 大公司里怎样开发和部署前端代码。
对于静态文件,第一次获取之后,文件内容没改变的话,浏览器直接读取缓存文件即可。那如果缓存设置过长,文件要更新怎么办呢?嗯,以文件内容的 MD5 作为文件名就是一个不错的解决方案。来看下用 webpack 应该怎样实现
1 2 3 4 |
|
打包后的文件名加入了 hash 值
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
手动调用 webpack 的 API,获取打包后的文件名,通过 writeTemplate更新 html 代码。完整代码猛戳 gitst。这样子,我们就可以把文件的缓存设置得很长,而不用担心更新问题。