[webpack]中小型多页面应用整合webpack终极方案

现在前端模块化、es6、MVVM这么火，附带的在学习使用这些知识时或多或少都会接触到webpack。 这里我不会去讲webpack本身的知识，这些东西都烂大街了一搜一大把。

通过本文你将会了解到如何将webpack引入到一个传统的多页面项目（如：商城）中去，借助webpack让我们能够使用es6、能够实现我们的模块化方案

注意：仅指中小型多页面项目

一，传统多页面的特点

• 一个页面对应一个url
• 功能串插混乱，一个页面要引入很多执行不到的代码
• 开发和版本迭代时代码管理难度大
• 使用文件hash控制缓存难度大，使用版本号控制缓存发布时又会出现各种缓存更新问题

二，思考

• 功能复用和代码组织通过模块化的方式很容易解决这个痛点
• 多url页面如何引入带hash的资源文件
  • 使用webpack单入口的方式？最终导致的结果是单个资源文件过大，无法有效利用缓存也会导致单次文件下载时间过长，所以不可取
  • 使用webpack多入口的方式？多url对应多入口貌似很有搞头

现在问题又来了，使用多入口必定设计到拆分的概念，将原本一个入口拆分成多个入口这需要一个什么样的标准呢，这就是接下来要讲的核心内容了

三，解决方案

有后端开发（如php）经验的同学知道在写业务逻辑代码时主要涉及到的是MVC中的C层（controller）,controller中会实现一系列的action，controller/action的组合也就实现了我们的页面url(www.xxx.com/controllerName/actionName)

1，现在我们来捋一捋上面的过程

• 一个controller里面会有多个action
• controller/action 对应一个url页面
• controller/* 表示一系列处于同一个controlelr下的url页面
• controller表示有业务关联的一系列url页面

现在不知道大家有没有理解清楚，后端将有业务关联的action写到同一个controller中，所以前端同理可以将有业务关联的多个url页面打包起来看成一个SPA应用（文中提到的SPA非真正的SPA，只是用来帮助理解）

2，开始拆分了（以商城系统为例）

• 首页SPA（首页比较重要一般独立出来）
• 商品SPA(商品详情页，商品列表，商品搜索页)
• 购物车SPA(购物车列表，付款页，结算页)
• 用户SPA（登录，注册，找回密码一系列）
• 会员中心SPA（一般的商城会员中心功能比较简单可以不用拆分，如果比较复杂自己可以按照同样的思路进行拆分）
• 促销SPA（视商城的业务定）
• 活动页（活动页一般不建议进行打包，可单独使用传统的方案）

这样我们就把商城这一个按业务拆分为多个（首页、商品、购物车、用户、会员中心、促销...）

3,一图胜千言

随手画的，哈哈哈~

4，项目目录结构

5，webpack入口配置

总结

从头看一下整个过程

• 按业务将整个系统拆分为多个前端项目（SPA）
• 打包SPA包含的url页面代码

整个过程经历了从一到多，再从多到一

webpack这么火你还没用吗？还不赶快尝试下。已经在使用了？也希望本文能给你不一样的思路

---

文中有表述不准确的或者有相关建议的欢迎在下面留言（'.'）