前言：公司老项目与JAVA后端的接口请求地址是通过注入一个global.baseUrl的方式引用,当进行本地开发的时候需要开发人员手动修改baseUrl指向mock data的url。若想请求test环境的后端接口则需将baseUrl修改成test环境的url，会出现老生常谈的跨域问题！
思考
跨域问题的解决方式网上一查一大把，这边就不废话。仅做思路的记录
- chrome方面介入，使用--disable-web-security在浏览器层禁用同源策略。优点：不需要改动代码，开箱即用。缺点：不知道该方法啥时候会挂，不能彻底解决开发中跨域的根本问题。
- 开发环境下前端node层开启一个proxy代理服务，将请求的地址指向test环境的URL。
- 后端处理，暂不考虑。
前期准备
添加代理用到了npm模块 http-proxy-middleware
$ npm install --save-dev http-proxy-middleware
复制代码对可能用到的基本配置进行简单说明下，已添加注释
var express = require('express')
var proxy = require('http-proxy-middleware')
var options = {
target: 'http://www.example.org', // 目标地址
changeOrigin: true, // 是否修改origin为目标地址的origin
pathRewrite: {
'^/api/old-path': '/api/new-path', // 将请求的old-path 解析为new-path
},
}
var exampleProxy = proxy(options)
var app = express()
app.use('/api', exampleProxy)
app.listen(3000)
复制代码项目间的差异性
现在很多的脚手架内置的webpack中webpack-dev-server中有一个proxy属性，配置起来相当简单。
// webpack-dev-server的配置
devServer: {
...
hot: true,
port: 3000,
host: '10.0.0.9',
proxy: {
'/test/*': {
target: 'http://localhost',
changeOrigin: true,
secure: false
}
}
复制代码在这个老项目中，采用的gulp+webpack的打包方式。当然现在的项目基本来说都是用webpack咯。
- webpack 主要以entry文件为入口形成的依赖链，对依赖文件的类型，进行监听，loader任务，打包合并，专业处理打包各种规范模块。
- gulp 主要以监听物理目录下文件，执行进行配置的任务流。
来看看build的目录结构
- 很通用的webpack2的项目实践方式，将不同环境下的不同webpack配置分离出来，通过webpack.DefinePlugin注入当前环境变量的方式区分(dev/test/prod等)
- gulp里面build.js里面完成了对静态文件的打包压缩生成/上传CDN等等操作，本次重点在于本地开发下dev.js。
express + http-proxy-middleware
扯了半天题外话，进入正题。 通过阅读dev.js代码发现是通过server()函数开启一个express用于本地开发，其实也就是同理于webpack-dev-server。 把上面准备工作中的实例代码结合自己的实际需求直接撸进去就行，伪代码如下
var proxy = require("http-proxy-middleware");
var proxyOpts = {
target: config.proxy,
changeOrigin: true
};
express().use("/", proxy(proxyOpts));
复制代码为了区分proxyToTest还是toMock，安装一波minimist(解析命令行后面所携带的参数)，多写个命令脚本吧
var minimist = require("minimist");
var options = minimist(process.argv.slice(2));
复制代码当执行gulp dev --proxy时，options = { _: [ 'dev' ], proxy: true }
运行
npm run proxy
复制代码[HPM] Proxy created: / -> http://demo.com
可看到"/"都被成功代理到http://demo.com下。完结撒花~