Webpack在”多页“开发中遇到的问题

在开发时我们经常使用Webpack官方提供的webpack-dev-server插件。我们只需要通过一个入口main.js和入口页面HTML,用webpack-dev-server就能够提供热更新“Live Reload”以及热替换“Hot Module Replacement”(即HMR) ,这很方便,但是在实际项目中我们遇到了更复杂的场景。

举例来说,我们现在的一个项目中不仅仅只是一个SPA应用了,它可能是由多个SPA应用构成的一个项目,每个SPA应用可能会由不同的人维护。因此它会有多个入口JS和入口HTML。由于没有提供唯一的入口js和html,仅仅使用webpack-dev-server的方案就行不通了。对于这种”多页应用“的项目,最好的方案是在开发时能通过路由切换到对应的SPA应用下,即对应的入口JS和HTML下,为此我们需要一些小技巧。

解决方案

其实在使用Webpack以前其实我们不会有这种烦恼,也许这就是“螺旋式上升”的必经之路。总之,我一开始能想到的方案有以下三种。

  1. 在开发模式下通过Gulp监听文件变化,然后直接使用Webpack打包出文件,用Gulp-Server处理路由。
  2. 任然使用webpack-dev-server,通过proxy代理另一个Server处理路由。
  3. 只起一个Server + WebpackMiddleware 在保留热更新和热替换的基础上,增加多路由。

三种方法各有利弊。在此我们选择第三种方式,通过独立Server我们能够更方便的处理Mock中Post请求以及Prox等问题,自由度更大。

server.png
图片中的multientry-dev-server就是接下来我们要创造的server。

Webpack Dev\Hot Middleware

官方提供的webpack-dev-server也只是一个用Express起的Server而已,其中使用了webpack-dev-middlewarewebpack-hot-middleware作为中间件提供Hot Module Replacement/Hot Reloading能力。Webpack Hot Middleware 必须要搭配Webpack Dev Middleware才能使用,因此同样的我们也可以用Express启动一个有热替换功能的服务器,webpack-dev-server只是做了一个简单的封装而已。

1
2
3
4
5
var http = require('http');
var express = require('express');
var path = require('path');
var webpackMiddleware = require('webpack-dev-middleware');
var webpackHotMiddleware = require('webpack-hot-middleware');

通过下面的代码建立Webpack的实例以及使用中间件

1
2
3
4
5
6
7
var app = express();
var compiler = webpack(webpackConfig);
var middleware = webpackMiddleware(compiler, {
publicPath: webpackConfig.output.publicPath
});
app.use(middleware);
app.use(webpackHotMiddleware(compiler));

通过路由获取内存中的Webapck打包文件

使用webpack中间件打包并不会真正的生成文件,它会把文件载入到内存中。
为了能通过路由指定跳转到对应的入口JS和HTML,我们在需在项目中做一些约定。假设项目入口为apps目录,该目录下的每一个子目录对应一个SPA应用,在子目录中需要通过一个package.json指定该SPA应用的入口JS和这个SPA应用的其他信息,比如名字和子应用负责人等。
基础模板1.png
package.json文件格式类似如下:

1
2
3
4
5
{
"name": "app1",
"main": "./main.js",
"author": "左伦"
}

middleware提供了middleware.fileSystem.readFileSync方法读取内存中的文件,文件的地址就是在webpack中配置的输出地址。

1
2
3
4
5
6
7
8
9
10
11
12
13
app.get('/:appName', function (req, res) {
var result = '';
var htmlPath = path.join(__dirname, webpackConfig.output.path + req.params.appName + '/index.html');
console.log(htmlPath);
try {
result = middleware.fileSystem
.readFileSync(htmlPath);
} catch (err) {
result = err.toString();
}
res.write(result);
res.end();
});

OK, 至此便可以通过路由指定到对应App的入口。

Mock数据以及“首页”

由于是独立启动的Server,我们可以很方便的在Server中指定任意目录作为我们的静态目录,同时处理好对应的Post请求。

1
2
3
4
5
6
// 静态资源,Mock GET请求
app.use(express.static(path.join(__dirname, '../')));
// Mock POST请求
app.post('/api/*', function (req, res) {
res.sendFile(path.join(__dirname, '../api', req.params[0]));
});

当越来越多的子App在项目中后,通过手动在浏览器中输入路由再进行跳转会显得十分麻烦。因此可以在Server中新增一个“首页”,列出当前项目下的所有子应用以及开发时的对应路由,具体实现并不难,通过遍历目录下每个应用中的Packge.json即可,最后效果如下:
屏幕快照 2016-12-11 下午7.11.20.png
终于不用每次在浏览器中敲地址了..
到目前为止,已经成功解决了Webpack在“多页“应用下的开发问题,接下来是时候更进一步了。

使用target指定入口应用

之前说到Webpack中间件在构建时会把文件都读取到内存中,但是当我们的项目越来越大的时候,项目下会有越来越多的子应用,这就造成了另一问题。有时我们只是在开发某一个子App下的代码,但是Webpack每次都会把整个项目打包进内存,非常浪费资源。因此这里我们可以在webpack的配置文件中做点文章,想办法只打包我们需要的目录下的JS。

在执行npm start的时候,通过在命令行里用

1
target=appName1,appName2 npm start

其中appName为你想要启动的应用名称(名称在package.json中定义),此时Webpack配置中的Entry只会包含target指定应用名下的入口JS和HTML,大大缩短了Webpack启动时间并且减少了内存占用。这个想法最初是在团队的另一位师兄的代码中看到的,十分巧妙,关键代码如下:

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
var targetEntries = process.env.target;
targetEntries = targetEntries ? targetEntries.split(',') : '';
targetEntries.forEach(function (value) {
console.log('应用: ', value);
entryPath = path.join(viewsDir, value);
entryJson = fse.readJsonSync(path.join(entryPath, '/package.json'));
entryMap[value] = [path.resolve(path.join(entryPath, entryJson.main))];
var appName = entryJson.name;
var tplPath = path.join(entryPath, '/index.html');
var conf = {
template: tplPath,
filename: path.join(appName, 'index.html'),
inject: 'body',
chunks: [appName]
};
htmlPluginsArr.push(new HtmlWebpackPlugin(conf));
});
_.extend(webpackConfig, {
entry: entryMap,
output: {
path: path.join(__dirname, '../build/'),
filename: '[name]/[name].min.js'
},
plugins: [
new ExtractTextPlugin('[name]/[name].css'),
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false,
drop_console: true
}
})
].concat(htmlPluginsArr)
});

通过这样一个简单的服务,我们完全不用再使用Webpack-Dev-Server了,甚至我们也可以封装成一个相似的plugin。整个问题的思路和解决方案到此为止咯,如果大家有更好的想法可以补充。

文章首发于alisec-ued ,个人博客地址