Table of Contents generated with DocToc
Multi-Page Application Server-Side Rendering，多页面后端渲染。
- 多页面，后端直出数据渲染模板生成页面，SEO友好
- 模板同构，前后端使用相同模板，前端无缝开发调试
- 面向页面和组件开发，并支持碎片，（页面/组件/模板/样式表）自由构造组合，主张局部按需提升
- 关注面分离，代码文件路径体现代码职责
- 支持Px2rem + DPR方案做（移动端）样式适配
- 支持PWA的Service Worker用于浏览器缓存
- Webpack资源打包，代码切分，静态资源文件遵从文件名变当且仅当文件变的原则，支持强缓存
- WebpackDevServer + HMR + Mock数据 + 接口代理 + 路由，本地快速开发
- 默认配置Babel转译JS代码，默认配置Sass和Postcss处理CSS
- 默认面向移动端，可以兼容桌面端
| 路径 | 内容 |
|---|---|
| src | 项目源码 |
| src/module | 模块（组件） |
| src/page | 页面 |
| src/script | 公用逻辑 |
| src/snippet | 碎片文件 |
| src/static | 公用静态文件 |
| dist | 发布文件 |
| mock | 开发测试数据 |
| build | 构建脚本 |
| test | 测试服务 |
由于面向页面和组件开发，开发代码主要涉及三个目录：
page目录，每个页面一个文件夹- 每个页面下，index.html为页面模板入口，index.js为页面逻辑入口
module目录，每个模块（组件）一个文件夹- 每个模块下，index.html为模块模板入口，index.js为模块逻辑入口（导出一个初始化函数）
- 作为模块，必须有自己的js（index.js，哪怕内容为空），并且被引用者require
script目录，公用脚本- 建议根据业务逻辑相关性作子目录区分，例如helper目录是业务逻辑相关的公用逻辑，util目录是业务逻辑无关的工具和辅助
开发可参照src中示例。示例包含2个页面（列表页和详情页），共3个模块（头部模块、列表模块、详情模块）。
$ npm run clean && npm run build:dll && npm run build:local$ npm run clean && npm run build:dll && npm run build && npm run serve打印所有页面所有模块依赖：
$ npm run tree例如对于示例，输出：
├─ [page] detail
│ ├─ [module] header
│ └─ [module] detail
└─ [page] list
├─ [module] header
└─ [module] list
默认只打印页面和模块，如果需要显示到模板的粒度，加-t选项：
$ npm run tree -- -t例如对于示例，输出：
├─ [page] detail
│ ├─ snippet/head.html
│ │ ├─ snippet/meta.html
│ │ └─ snippet/css.ejs
│ ├─ [module] header
│ ├─ [module] detail
│ │ └─ module/list/item.html
│ └─ snippet/js.ejs
└─ [page] list
├─ snippet/head.html
│ ├─ snippet/meta.html
│ └─ snippet/css.ejs
├─ [module] header
├─ [module] list
│ └─ module/list/list.html
│ └─ module/list/item.html
└─ snippet/js.ejs
如果只需查看特定页面，加页面名：
$ npm run tree -- page_name例如对于示例中的list页面，输出：
└─ [page] list
├─ [module] header
└─ [module] list
在build/config.json中，resourceVisitPath选项是静态资源的路径，在构建非本地环境时，修改为需要的路径，如//res-domain.com/res-dir/。
$ npm run build:dll建议环境：pre、prod。
$ npm run build如果只需要构建某一页面，则指定该页面：
$ npm run build -- page_name不压缩代码。建议环境：dev、test。
$ npm run build:devel如果只需要构建某一页面，则指定该页面。
结合mock数据，使用Webpack DevServer和热加载，本地开发调试。
$ npm run build:local如果只需要构建某一页面，则指定该页面。
本地服务支持Mock接口、代理接口和路由，用于开发和测试。本地服务分两种情况，本地开发模式下随Webpack启动的Webpack DevServer，本地测试模式下（构建了非本地环境的代码后想要本地预览和测试）手动启动的服务器。
如果是本地开发环境，则默认使用Webpack DevServer，在构建命令执行时会自动启动。
如果已经构建了测试或正式环境的代码，想要预览效果，则手动启动本地测试服务，即执行：
$ npm run serve
在build/server.config.js中，before(app)配置Mock接口，proxy配置代理接口。
Mock数据可以额外定义在mock文件夹中。Mock数据分两种，页面直出数据、接口数据。
页面直出数据在两个时候被使用：
- 本地开发模式下，在Webpack编译时，html-webpack-plugin插件将页面模板与页面Mock数据合成html
- 本地测试模式下，服务器对每个页面名称提供对应接口，返回页面模板与页面Mock数据合成的html
对于页面直出数据，建议遵循page-${page_name}.json的命名规则。
在build/server.router.js中配置路由。
默认配置ESLint和StyleLint进行代码检查验证，并且为git配置pre-commit的hook。
如果git commit时报以下错：
: No such file or directory 2: ./node_modules/pre-commit/hook
则尝试换用终端，如Windows下可使用git bash。
如果git commit时不想进行验证，则在命令后加--no-verify选项。
存在分开打包需求的代码包括：
- 第三方库
- 跨页面的公共逻辑
- 页面内的业务逻辑
对于第三方库，使用externals和DllPlugin；使用DllPlugin需注意，在将dll包build完毕后再执行业务代码打包和DevServer。
对于公共逻辑代码，使用CommonsChunkPlugin。
Service Worker的使用是可选的。如果不需要，则在build/config.json配置文件中将serviceWorker置为false。
生产环境和测试环境下，建议在项目域根路经下代理service-worker.js文件和其他静态资源。
location /service-worker.js {
proxy_pass http://res-domain.com/res-dir/service-worker.js;
break;
}
location /resource-dir/ {
proxy_pass http://res-domain.com/res-dir/;
break;
}
当然，最好再在请求响应头里加上缓存相关的头。只要秉持“文件名变当且仅当文件变”的打包原则，缓存过期时间可以设置足够久。如果允许的话，还可以给项目域的res-dir路径配置cdn缓存，并且足够久。
测试环境如果SSL证书不受信，可以命令行带参数打开Chrome，让Chrome信任项目源和cdn源：
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --unsafely-treat-insecure-origin-as-secure=https://app-domain.com,https://res-domain.com --user-data-dir="D:\foo" https://app-domain.com
一般地，将桌面端俗称PC，将移动端俗称Wap或H5。如果是PC端并且需要兼容IE8-，那么需要调整部分文件。需要调整的文件都在自身所在目录下存在另一个同名（但名称中多出ie标识）文件，进行替换即可。