使用webpack前端架构反思

      距离上次写博客，大约已经有两年时间，而且之前题目写的也并非关于IT，而是关于股票期货与各个指数算法分析（假如你经历过2015年中国人的疯狂就会对我为什么要写个会深表同感，我从2011年炒股票到2015年完全放弃这个玩意），这次写博客的原因是对自己最近一段时间的工作回顾，选择是因为恰巧有机缘看到别人写过，且觉得的界面做的确实挺好看的（我觉得他们这个字体挺好看的）。

      前端H5作为近期在市场上非常火的一个技术方向，其实在很久之前是被各个工种的程序员所看不起认为比较很低端的技术（包括本人在内，作为一个前iOS程序猿曾经在一次面试时当着面试官表达过自己对H5这门技术的不屑一顾，如今被现实打脸，作为一个专职前端开发人员且不断的给自己挖坑），H5之所以受到市场上的青睐源于他的跨平台以及更新方便比如移动Hybird 应用以及普通web应用，而让他插上翅膀的则是nodejs的问世假如你知道且你了解CMD 语法你就会明白他对前端意义有多大，从美工到web前端开发工程师称谓上的变化足可证明，假如15年你学H5 前端，面试官对你的要求会相当之简单，熟悉H5与H4之间的差别熟悉CSS3，假如你对jsonp,dom结构，算法有一定了解恭喜你，你已经到达了一名美工的基本要求了，但如今我只能告诉你单靠这些你连美工都当不了，angular，vue,react,gulp,codova,grunt,express,sass,nwjs，typescript这些名词的出现大约刚好有两年，而nodejs已经更新到8点几版本了（如果你对这个没什么概念，你可以看下jdk的最新版本）。

      而这次写博客的主角则是webpack，作为一个前angular开发人员对于gulp之流使用算是有一定心得，但使用webpack则是从最近两周开始，主要原因是因为有个项目用vue，使用webpack，而在上周接到对于现有平台项目进行重构并且要兼容vue，（作为一个程序猿妥协与退让都是不存在的）大约经历了俩个小时（实际不到15分钟），立马给自己挖第一个坑，现有项目用vue重写框架统一工具统一后期维护方便，当然这个方案最后是被否了，开玩笑那么多项目要重写没个半年写的完？不过被否就被否思维活跃如本尊，想新方案不是分分钟在会议室里瞎扯淡半天，leader重新进来问讨论结果，一个idea从脑海闪过，使用webpack,做重构并且前后台完全分离，用e6语法做代码分割，做一个多页面版的web架构，leader对这个提议当然是相当赞同，原因简单啊对现有的架构迁移量不大啊，而且同时又起到了优化结构，实现代码管理的功能，最关键的是保住了jquery(去年一年我都坚持不用jQuery写代码而是坚持用javascript原生，现实总是习惯性的嘲讽你的无知与傲慢)。

    事情讲出来做得到就是有本事，做不到就是吹牛，而我这个人向来不习惯在工作这么正式的事上吹牛逼，所以说做就做，首先介绍下webpack从名字就能看出来他是web端的用node编写的打包工具可以将web端的文件进行打包发布，起到压缩以及代码伪装的作用（老式的网页一般都是程序猿手写发布可阅读性非常强，而且语法也是千奇百怪），极端点的甚至可以将web文件打包成gzip文件（知道的都说好不知道建议找百度老师），而且他也提供了一套开发插件比如webpack-serve,webpack-hot-middleware.webpack本身的option(官方不这么说，我这么叫写过插件的人都懂)分为entry，output，loader，plugin分别对应了文件入口，输出文件出口，文件编译规则,以及插件使用，期中比较强大的是loader和plugin,假如你是一名后台开发人员应该对中间件这个东西有一定了解这个也用法差不多，在一个loader里 假如我写一个{test/.js$/ ,rule:'babel'}那么当你的文件是js时他就会通过babel这个loader 来检查js 你可以用require module.exports 这种语法写js 也可以用import '' from '' export default 只要你在他的.babelrc文件里配置他支持的语法范围是es6以上或者cmd就行。介绍就这么多假如你不懂请您去看官网或者去慕课网看视频都是免费的。

   接下来就是讲架构的问题，前后端分离就表示前端项目要完全独立与后端来做，那么从开发，测试，部署，业务逻辑，vendor都要考虑进去，首先是前端的目录结构分为build,src,mock,vendor,config,test接下来一一解读重建这些目录的目的何在以及其中的二级目录以及文件。

    build目录是webpack的脚本目录在里面对应的是webpack.prod.js  webpack.test.js webpack.dev.js 分别对应生产，测试，开发环境配置当然运行的脚本文件不是这些，这些其实只是配置文件，我们要做的是一个多页面的前端组件化的东西，我们基本的配置文件也要组件化，所以我们在这个文件里有一个inherit的目录，这里面写的都是公用部分，比如entry,plugns.还有loader这些在项目中的共有部分比较多可以直接导出到外部合并，webpack.prod.js以及test和dev配置的区别在于首先要配置process.env的不同方便在脚本上对不同环境的做出不同的操作，比如assectPublicpath,以及path这个在webpack output中起到至关重要的作用假如你的文件都在同一目录下，那么可以配置assetPublicPath为相对路径这样在webpack-html-plugin中生成的src就是相对路径，假如你的这些文件都不在同一个目录甚至是不在同一个服务器中那么这个就很有必要了你可以配置assetPublicPath为绝对路径，这样生成的应用就是带域名的路径，在url-loader处理css的相对路径这个也起到非常大的作用，在prod和dev两个环境相同的是entry 不同的在开发中我们要的是高效所以不会对压缩伪装有要求，我们需要的是启动本地服务器，热更新等等插件，相同的是都会获取所有的入口文件，然后以数组的方式创建html-webpack-plugin生成多页面应用。

     src目录是我们的业务目录里面有三个大目录page和resource，component，page处理我们的页面模板（这里我用的是ejs模板引擎）以及业务逻辑同样CMD语法支持resource里有俩个子目录一个static另一个layout，static对应的是我们无法用cnpm包引用的老旧插件这个我直接用copy-webpack-plugn处理将他直接copy到build目录相关配置在config里，layout这个概念很好我也是借用但是对于组件化这个概念真的很棒，一般来说我们一个页面有header  nav body footer 这些小组件，也会有menulist conten这种小组件，layout 对应的是不同的布局方案，假如你写过freemarker这个你应该很熟，将页面里的小件凭借起来比起前端手写代码来说要省很多事,page里面调用layout的逻辑生成html共有部分再改我们只需要改component里面的小组件即可。

    vendor 对应的是我们第三方库主要是那些无法用npm包维护的库但我们在项目里要引用这，这个不得不提common-webpack-plugin的插件将多个项目里引用的打包到common中去，我们的目标是尽可能少的发起HTTP请求减少冗余代码。

  mock用过的人都知道前端在前后台分离时用的，在后台接口还么做好的时候可以写本地接口，最近听说一个叫markdown的东西假如你的后台兄弟愿意写给你，那你大可不必重建

    test单元测试用的karam的使用教程问百度老师吧，测试时开发环境的必要不少的环节，假如前端可以自动化测试，那么可以省去很多不必要的麻烦。

     目录介绍完就应该开始讲坑了，所谓装逼10分钟台下十年功，从这周六以及上周六都在焦虑中度过，直到今天项目跑起来后才算松口气，讲一讲最初架构的时候我并咩有这么想我想的简单粗暴，写一个像.vue这个的模板然后用import这种语法来插入就行了，我也是这么做的，事实是现实总会不断敲打你告诉你你还太年轻，当我用import 获取到路径然后用fs 获取文件文本再拼接成一个html模板后居然发现jQuery果然好强大，你想用复制黏贴的手法用jQuery 他会告诉你别太天真的，你连$符都找不到怎么用，报错报的你莫名其妙，只能通过外包导入以及webpack加alias这种方式，最神奇的是当时我就写了一个文件IO以及起了一个本地服务器电脑直接就卡死了，甚至于直接连启动都启动不了了，只能求助网管，还有就是bootstap编译，webpack有一个dll 预编译的文件可以编译那些只需要编译一次后面就不需要编译的文件，我用了bootstrap不行会报错外部引用也没用最后我走了copy-webpack-plugn这条路，并把所有的引入都写到header.

    这次的架构说的简单点就是用后台的思维做前端的多页面应用（vue这种SPA应用和这种多页面相比还是复杂的多所以才会有vuex这种存在），最终将前台文件打包，好处就是实现了组件化，以及前后台分离，减少http请求。坏处嘛就是前端的业务量将会继续上涨（不加没有意义的班，在电脑面前发呆不如回家睡觉，或者直接在桌上睡觉）