找了一大堆webpack教程，基本上都是新项目的建立结束，但是老项目怎么办，终于从网上搜索到了一篇，老项目改造的贴在这里。
感谢作者的智慧。
复制过来排版失效了，请查看原文https://2mih.com/2017/01/apply-webpack-in-old-prjects/
目前项目里的前端现状是：
多页应用
用JSP
作为模板技术，JSTL
、JSP
、JS
混搭
HTML
头部一一引入各种JavaScript
、CSS
框架或类库
大段的业务逻辑JS
代码直接内联在JSP
缺少模块化
缺少分层架构框架
完全重构是不可能的，也没这个必要，就想借着功能实现的机会顺带做做前端的模块化、打包等。
其实想模块化、组件化这些工程思想的实践未必一定要依赖于某种工具或框架，但是显然，工欲善其事，必先利其器嘛。之前用的是百度的F.I.S
，其实在功能实现、架构设计方面都挺优秀的，但是因为受众面还是不太广，工具的推广和常见问题的解决都不好说，所以选择了Webpack
。
模块化
模块化的改造工作量也不大，把大段的内联代码放大外联的JS
文件，模块方案这里选择的是CommonJS
，Webpack
对CommonJS
的支持不用说了，现在很多的类库都放NPM
了，CommonJS
用起来也方便。虽然简单，还是有很多坑的。
老项目最喜欢的就是什么都往在全局对象window
对象上放，单文件模块内的引用很好排查，快文件模块的引用就得好好利用文件查找了
eval
，是的，仍然有臭名昭著的eval
代码。eval
执行完的作用域为全局，我们做重构时，这些别忘了注册到window
上
喜闻乐见的jQuery
, 基本上出现在每段JS
代码中。我们可以用ProvidePlugin
，不用每个文件都require('jquery')
了
1
2
3
4
5
new webpack.ProvidePlugin({
$: "jquery",
jQuery: "jquery",
"window.jQuery": "jquery"
})
有些项目用的是BUI
，阿里出品，不幸已成为时代的遗弃儿，它兼容了阿里自己的CMD
，也就是sea.js
，还好配合Webpack
提供的一些插件，用shimming-modules基本完美兼容BUI
(还是得改一行BUI
的源码)，对还得配合CopyWebpackPlugin
来支持BUI
的按需引用能正常工作。
1
2
3
4
5
6
7
8
9
10
11
12
module: {
loaders: [{
test: /bui.js$/,
loader: 'imports?this=>window,define=>false'
}],
plugins: [
new CopyWebpackPlugin([{
from: 'src/libs/bui',
to: 'dist'
}])
]
}
后台管理项目自定义样式都很少，基本依靠UI框架，可以用Webpack
直接require
，也可以不用模块化，直接外联，业务模块少量的CSS
再require
进来
鉴于项目已有的JS
代码一般耦合都比较大，不是单页应用，又是内网项目，就没有做代码分割了，整个文件require
自动化
自动化说到底是因为有各种需求，包括文件压缩、用上最新的、加文件指纹等等，能让我们把时间和精力聚焦在业务代码上。这里基于实际的需求，还是有些可以尝试的点。
文件合并压缩
因为是内网系统，一个页面加载10+个外部资源也不会有任何问题，因为文件合并压缩是打包工具最基础的应用，这里就顺手做了，不多说了
文件指纹
以前的页面都是直接禁用缓存，原因同上，这里给静态文件名中加上文件hash
，然后启用缓存，加载速度肯定是秒开，但是并没有什么卵用。Webpack
的ChunkHash
有点问题，内容不变，ChunkHash
也会发生变化，Github Issues也有很多这方面的讨论，但我并没有去解决这个问题，每次发版本后，页面需要重新获取一遍没有变更的vendor
资源，这个对于我们来说是可以接受的。
自动生成HTML
既然用到非覆盖式的缓存方案，我们的主页面引用的静态资源URL
则会经常变动，很简单用HtmlWebpackPlugin
自动生成。
我们的后端用的JSP
，前端开发时目前还不能完全脱离后端，修改JSP
内容后，Webpack
自动生成新的JSP
，但是界面改动没有生效，因为Webpack
生成的内容都是处于内存，而我们访问JSP
是通过代理至后端Tomcat
，所以后端的JSP
没更新。
后面找了个HtmlWebpackHarddiskPlugin
插件，和HtmlWebpackPlugin
是同一个作者，配合使用可以将JSP
的改动实时刷新至磁盘，配合后端的热部署，可以实现JSP
内容自动刷新并生效。
Eclipse
默认支持JSP
的热部署，没毛病。但是Intellij
默认情况下不能完美支持(需要触发frame deactivation
才能刷新JSP
，因为我用单独的Atom
来写前端相关的，所以后面的Intellij
一直处于deactivation
)，太对不起他的名号了，还得配合JRebel
一起使用才能做到JSP
完美热部署。
自动刷新
自动刷新也是很能提高效率的一个点，Automatic Refresh写的还算详细具体，但我还是习惯于单独写个server.js
配合proxy
来new一个WebpackDevServer
1
2
3
4
5
6
7
8
9
10
11
12
var config = require('./webpack.config.js');
var compiler = webpack(config);
var server = new WebpackDevServer(compiler, {
publicPath: '...',
...,
proxy: {
'*': {
target: '...'
}
}
})
server.listen(9000);
部署
以前没有自动化，也就没有前端编译部署一说，都是后端部署，用的是Jenkins
，现在加了前端编译的过程，但由于我只是属于后台近20个多开发团队中的一个，就没有去推动后端项目的前端部署了，牵扯太大，还没到那个时候。所以我用的方案就是本地打包完，然后把dist
也上传至版本控制服务器，后端同事本地也不用搭node
环境，也挺ok的，只是每次都要上传新的文件至SVN
。
前端框架
组里几大项目都是BUI
大行其道，交互往哪边，代码就超哪边写。很显然，就算组织的再好，也很容易失控，所以我就琢磨着给弄个MVVM
框架，特别是当下的React
炙手可热，我在上一家公司用的还是Backbone
和Marionette
，React
只写了下Demo，这次也想尝试下。但是几经考察和思虑后，还是打算引入Vue
。主要基于以下考虑：
React
引入的话，redux
、react-redux
估计是逃不了的，JSX
也要跟着来，还有React
相关的一堆概念
Vue
的确是它官网写的渐进式的，甚至不用打包都能引入，在老项目上加点内容时，通过外联JS
方式引入Vue
，new
几个VM来实现功能还是很舒服的，也能用比较激进的组件化Vue
单个文件来构建
Vue
的API
真的比React
要友好，各种概念的理解也较React
系的要简单，这个对框架的内部推广作用应该挺大，毕竟这里不是专业前端队伍
React
的生态确实比较好，各种UI
库也很多，但是Vue
的势头也不错，UI
库有个饿了么团队的Element
，质量也不错，够用了
总而言之，比较之下Vue
的引入成本要低一些，后面实践起来也确实不赖，旧的项目之间简单的用用数据绑定功能，新的项目，直接上了Vue 2 + Vuex + ES6 + ElementUI + Webpack
，应该说在效率和框架实践二者之间达到了一个平衡。
单页应用/组件化
旧项目基本都是多页应用，自然代码也是按照route
来组织的，虽然组件化谈不上，但好各个功能模块之间歹有个边界，不至于失控。新项目，经过考虑，我也没有采用单页应用的实现方案，主要是基于这里的整体IT架构实际情况吧，单页应用必然要在前端做路由，后端要做同步改造，还有权限的控制问题等。
组件化在新的项目中慢慢实践起来，各个功能组件不用说了，通用的UI组件也要多抽象。
其他
实际项目远比写Demo要来的残酷，关键还是要看实际场景，解决实际问题。
我们开发的环境是连不了外网的，我的node_modules
哪儿来的呢，从办公环境拷贝过来的，升级就要从外面升好，再拷进来。
虽然这个年代不用兼容IE了，但是还得兼容IE，我们就有必须IE才能访问的系统，还好可以强制升级IE11。
是不是我们的页面都是打开浏览器进入的呢，这个也不一定，内嵌在某个地方也有可能，对吧。
这里的前端工作没有那么的酷炫，老项目不可怕，解决实实在在的问题，自发的去优化和改进代码、流程，才能打造质量更高的产品以及效率更高的开发模式。今天，1月18日，Webpack 2
终于发了正式版本了，可喜可贺。
YidaZh2017-01-18
