webpack多页应用架构系列（一）：一步一步解决架构痛点

本文首发于Array_Huang的技术博客——实用至上，非经作者同意，请勿转载。
原文地址：https://segmentfault.com/a/1190000006843916
如果您对本系列文章感兴趣，欢迎关注订阅这里：https://segmentfault.com/blog/array_huang

这系列文章讲什么？

本系列文章主要介绍如何用webpack这一当前流行的构建工具来设计一个多页应用的架构。请注意，本文并非新手教程，着重点更多是在于提供解决问题的思路，而非手把手带你装逼。

作者介绍

本人供职于某互联网物流公司，专职前端，公司虽仍处于创业阶段，但产品线已经拉得挺长的了，因此所碰到的痒点、痛点也不少。我本是PHPer出身，对传统前端茹毛饮血的境况恨之入骨，幸得webpack这一神器，我感觉现在写前端已经跟写PHP差不多了（大误）。

示例代码

诸位看本系列文章，搭配我的脚手架项目食用更佳哦（笑）：Array-Huang/webpack-seed(https://github.com/Array-Huang/webpack-seed)。
上个文件目录结构让大家一睹为快：

├─build # 编译后生成的所有代码、资源（图片、字体等，虽然只是简单的从源目录迁移过来）
├─node_modules # 利用npm管理的所有包及其依赖
├─vendor # 所有不能用npm管理的第三方库
├─.babelrc # babel的配置文件
├─.eslintrc # ESLint的配置文件
├─index.html # 仅作为重定向使用
├─package.json # npm的配置文件
├─webpack.config.js # webpack的配置文件
├─src # 当前项目的源码
    ├─pages # 各个页面独有的部分，如入口文件、只有该页面使用到的css、模板文件等
    │  ├─alert # 业务模块
    │  │  └─index # 具体页面
    │  ├─index # 业务模块
    │  │  ├─index # 具体页面
    │  │  └─login # 具体页面
    │  │      └─templates # 如果一个页面的HTML比较复杂，可以分成多块再拼在一起
    │  └─user # 业务模块
    │      ├─edit-password # 具体页面
    │      └─modify-info # 具体页面
    └─public-resource # 各个页面使用到的公共资源
        ├─components # 组件，可以是纯HTML，也可以包含js/css/image等，看自己需要
        │  ├─footer # 页尾
        │  ├─header # 页头
        │  ├─side-menu # 侧边栏
        │  └─top-nav # 顶部菜单
        ├─config # 各种配置文件
        ├─iconfont # iconfont的字体文件
        ├─imgs # 公用的图片资源
        ├─layout # UI布局，组织各个组件拼起来，因应需要可以有不同的布局套路
        │  ├─layout # 具体的布局套路
        │  └─layout-without-nav # 具体的布局套路
        ├─less # less文件，用sass的也可以，又或者是纯css
        │  ├─base-dir
        │  ├─components-dir # 如果组件本身不需要js的，那么要加载组件的css比较困难，我建议可以直接用less来加载
        │  └─base.less # 组织所有的less文件
        ├─libs # 与业务逻辑无关的库都可以放到这里
        └─logic # 业务逻辑

架构痛点痒点一览（并非系列文章的所有内容）

SPA好复杂，我还是喜欢传统的多页应用怎么破？又或是，我司项目需要后端渲染，页面模板怎么出？
每个页面相同的UI布局好难维护，UI稍微改一点就要到每个页面去改，好麻烦还容易漏，怎么破？
除js外的资源如css/less、图片、swf、字体等，要怎么打包呢？不然老是要外部引用，迁移、部署起来都好麻烦呢。
某些年久失修的jQuery插件怎么在webpack里使用呢？
能不能整合进ESLint来检查语法？
能不能整合postcss来加强浏览器兼容性？
部署代码的时候如何清除用户浏览器遗留下来的上个版本的缓存？

后续发展

我相信，架构不是一蹴而就的，而是一个不断迭代的过程，每跨过一个坑、每解决一个痛点痒点，都能使架构更加健壮；因此，我也将把我后续对架构的优化继续撰写成文章（不过当然是先把目前架构的内容写完啦哈哈哈哈），并相应地改写示例代码（其实说不定是我先在示例代码试验过后再搬到实际项目里使用呢）。

附系列文章目录（同步更新）