开发者社区> 青衫无名> 正文

进阶:构建具备版本管理能力的项目

简介: webpack是时下十分流行的编译和打包工具,它提供一种可扩展的loader的方式,简单的配置,便可以编译打包各类型的文件,包括js、css、image、font、html,以及各种预编译语言都不在话下。
+关注继续查看

webpack是时下十分流行的编译和打包工具,它提供一种可扩展的loader的方式,简单的配置,便可以编译打包各类型的文件,包括js、css、image、font、html,以及各种预编译语言都不在话下。

一、回顾与思考

在上一节的【入门:十分钟自动化构建】中我们讲解了如何用gulp去搭建一个工作流。我们认识到gulp是一个流程管理工具,以单个任务为基础单元,组合成为一套完整的工作流,而且gulp还有很多的以gulp-*格式命名的工作模块,用来处理各种资源文件,如果没有看过上一节内容的同学,建议先回去看过,再往下阅读,因为本节内容是跟上一节的知识点紧密联系的。

这一节我们会讲解如何构建具备版本管理能力的项目,什么是版本管理能力?不是什么svn或者branch,我们看这样一个场景来帮助理解:

你用上次搭建的工作流开发了一个网站,然后上线。

第二天打开发现有bug,心想尼玛赶紧趁着老板没发现修复一下。

改完代码,打包,发布,一气呵成,完美。

然而十分钟以后老板让你去一趟办公室,打开页面跟你说有个bug。心里一抽,一看!我勒个去,这坑爹的缓存啊。。。

怎么去解决这个缓存?,或者说,怎么保证我上线一个新版本,可以完完全全地替代旧版本?这就是版本管理。

这问题有很多解决方法,包括手动打个戳啊什么的,像src="a.jpg?201608062315",这确实可以解决,但是如果一次更新的东西很多,你压根改不过来。

gulp能帮我们做这事吗?可以,麻烦,有兴趣的同学可以自行搜索资料。有没有简单点的套路?有的,webpack天然支持这一功能。接下来我们就介绍如何用webpack来搭建这么一套工作流。

二、webpack

webpack的用法,我们简单介绍一下。跟gulp一样,webpack也是写好配置文件才能开始工作。

全局安装webpack

npm install webpack -g

记得养成好习惯,也本地安装一下哦

npm install webpack --save-dev

顺带我们把接下来要用到的几个loader一起安装了:

npm install style-loader css-loader sass-loader swig-loader --save-dev

这里的*-loader作用跟gulp-*差不多,就是一些编译用的模块。

紧接着我们在根目录下,新建一个webpack.config.js配置文件,我们直接来看代码:

var path = require('path')

module.exports = {
 entry: {
 Index: ['./src/js/index.js']
 },
 output: {
 path: path.resolve(__dirname, './dist/static'),
 publicPath: 'static/',
 filename: '[name].js'
 },
 resolve: {
 extensions: ['', '.js', '.scss', '.swig']
 },
 module: {
 loaders: [
 {
 test: /\.css$/,
 loader: 'style!css'
 },
 {
 test: /\.scss$/,
 loader: 'style!css!sass'
 },
 {
 test: /\.swig$/,
 loader: 'swig'
 }
 ]
 }
}

这里大致分为四部分的内容:
entry
入口文件,也就是一切工作的起点,你可以将整个web应用都最终打包成一个js文件,那你只需要定义一个入口,而如果你希望对多个页面独立开来,你需要定义多个入口,最终在不同的页面引用不同的js。一个entry对应生成一个bundle。

output
定义打包输出的配置:

  • path是打包文件的存放路径,按上面的配置,意味着我们待会打包的文件是要放在dist/static下的;
  • publicPath是定义文件被打包后的url前缀的,效果是


原文发布时间:2016-08-16

原文作者:Jack_Lo

本文来源掘金如需转载请紧急联系作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
前端自动化集成部署交付实践
随着前后端分离应用模式的推广,前端项目可独立部署维护上线,不再仅仅将前端开发后打包的文件直接丢到一个文件目录下就完事大吉了,现在对前端来说也需要了解运维的相关知识,本文旨在介绍一些相关的运维概念以及一些前端运维的实践。
23 0
从零开始搭建一个通用的业务技术架构,这套架构有点牛逼!
从零开始搭建一个通用的业务技术架构,这套架构有点牛逼!
32 0
KubeVela 项目和能力简介 | 学习笔记
快速学习 KubeVela 项目和能力简介
267 0
3.0基础概念:工程管理及构建|学习笔记
快速学习3.0基础概念:工程管理及构建
31 0
第4天-CICD+K8S综合实战-1
第4天-CICD+K8S综合实战-1
68 0
第4天-CICD+K8S综合实战-2
第4天-CICD+K8S综合实战-2
689 0
KubeVela 插件指南:轻松扩展你的平台专属能力
本文作者为 KubeVela 社区贡献者 姜洪烨。 我在原文基础上做了适量修改。KubeVela 插件(addon)可以方便地扩展 KubeVela 的能力。正如我们所知,KubeVela 是一个微内核高度可扩展的平台,用户可以通过 模块定义(Definition)扩展 KubeVela 的系统能力,而 KubeVela 插件正是方便将这些自定义扩展及其依赖打包并分发的核心功能。不仅如此,Kube
94 0
混合环境应用交付实践| 学习笔记
快速学习混合环境应用交付实践。
37 0
KubeVela 1.4:让应用交付更安全、上手更简单、过程更透明
在这次发布的 1.4 版本中,我们围绕让应用交付更安全、上手更简单、过程更透明三个核心,加入了包括多集群权限认证和授权、复杂资源拓扑展示、一键安装控制平面等核心功能,全面加固了多租户场景下的交付安全性,提升了应用开发和交付的一致性体验,也让应用交付过程更加透明化。
379 0
Devops 开发运维高级篇之微服务持续集成代码上传和代码检查
微服务持续集成(1)-项目代码上传到Gitlab 微服务持续集成(2)-从Gitlab拉取项目源码 微服务持续集成(3)-提交到SonarQube代码审查
100 0
+关注
青衫无名
文章
问答
视频
文章排行榜
最热
最新
相关电子书
更多
无需从0开发 1天上手只能语音离在线方案
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载