基于vue脚手架的项目打包上线(发布)方法和误区

原文链接: http://www.cnblogs.com/amingxiansen/p/9789388.html

最近要把vue脚手架开发的一个项目上线,只知道vue脚手架是基于node的服务端项目,那么只需要 npm run dev 就可以轻松启动整个项目,当我想当然的给服务器配置合适的node环境(这里也遇到了坑,服务器系统对node版本的兼容性等),然后想当然的把整个项目源文件拷贝到服务器上,满心欢喜地去线上测试~~

悲剧发生了,停在启动页(首页)迟迟没有反应。我嘞个去,一看network请求,app.js这个被webpack打包的引用依赖文件足足14.7M,我的天,我用的测试服务器只有1M的带宽,也就是说客户机网络足够快,再忽略掉传输损耗等因素,这个页面也得加载十几秒(理想状态下)。实际的情况是一两分钟之后app.js才能加载完成,开始首页渲染。这肯定是不能接受的情况。

怎么解决呢?我的踩坑过程是这样的(如果是一步到位看最终解决方案,请跳过,直接看最后一部分)

1.找寻webpack打包app.js的原理和优化方案,没想到网上遇到这种情况的还挺多,

于是乎,就按照上面的方案去做,把vue\vue-resouce、vue-router等取消本地依赖打包,换成静态资源外链的形式,当然也用了路由懒加载,app.js突飞猛进缩小到了8M,但是还是不行啊,加载时间还是1min左右。当时的目标是能缩减到2M左右,这样作为开发者的我还算能接受,用户能不能接受我就不知道了。哈哈哈。

项目中用到了echart和v-chart这两个东西比较大。感觉肯定吃掉了我很大的空间,预示就想把他们外链出去,想法是对的,但是v-charts的外链依然碰壁连连。确实这样做貌似也看到了曙光,app.js可以缩小到3M,但是v-charts在项目中不起作用了,所以说我可能看到的只是假象。

2.基于前面的尝试,让我觉得应该寄希望于webpack打包机制,于是乎做好了啃新的准备,看了一上午,把代码优化到7M左右,效果不明显啊!

我甚至觉得我之前的依赖有多余的吧,要不要精简一下,但是不好下手,删一个就报错。准备重构项目了!又去安装了脚手架的3.0版,哎,3.0.和2.0还是差别蛮大的,也是一鼻子灰。

然后就是最后的解决方法了,其实就是一个误区啦!!(稍后更新)

3.误区解读:其实vue脚手架本身就提供两种模式 开发模式&生产模式  也就是npm run dev&npm run build;我们发布版本上线的时候是要用生产模式,打包之后的文件目录格式是这样的:

生成dist文件夹就是你可以直接放到服务器上的文件,其中包括了静态资源文件,还有那些依赖文件都已经打包进index.html并且进行了压缩。

值得注意的是当你用build打包的时候有个地方的配置需要改一下:看下图

这两个地方之前是原本静态资源的相对路径,因为打包完之后index和static文件夹在同一目录下,所以改成当前路径。

一直以来的误区就是脚手架必须依赖与node环境,实际不然,只是开发模式,发布之后就是普通的html,可以跑在之前的服务器下。

这样一来,你会发现app.js和vendor.js都不过几百K的大小,一般超不过1M,运行速度大大提高。

上面说到的vue脚手架其实不准确,应该是基于vue脚手架和elementui的开源后台管理项目vueAdmin!(并非原生的vue脚手架,不过除了启动命令没太大区别,原生命令看这里)在GitHub 上有源码。

转载于:https://www.cnblogs.com/amingxiansen/p/9789388.html

猜你喜欢

转载自blog.csdn.net/weixin_30797199/article/details/94931942