浅谈前端开发中的版本管理

软件开发和发布过程当中，版本是个极其重要的因素。大至操做系统，小到功能组件，都会涉及到版本相关的问题。本文主要讨论了静态资源的版本管理，以及前端开发使用npm以后npm包管理的相关内容。

静态资源

浏览器缓存在减小资源请求、加快页面载入速度的同时，也给开发者带来新的问题：新发布的资源由于缓存问题而没法被成功载入。在此状况下，轻会致使新的功能没法展现，重可能会由于资源不兼容致使页面报错、功能没法使用。为了解决这一类的问题，开发者每每会在静态资源信息中添加版本信息。

版本号的来源

每次发布都不同的值便可做为版本号来源，因此版本号能够自定义而且手工维护，也能够是发布时的时间戳的md5的值，或是经过各种工具自动生成的值。

• 自定义版本号
  自定义的版本号简洁明了，可以清楚地知道版本的信息，可是弊端在于，须要手工的去维护版本信息。

• 自动生成的版本号
  将时间戳、动态hash等自动生成的信息做为版本号也是比较常见的方法。在打包脚本中配置好相关信息以后，再也不须要额外的干预便可自动生成版本信息。

经过webpack打包静态资源文件属于比较常见的作法，webpack中的hash/chunkhash/contenthash实现的版本号即属于自动生成的版本信息，经过适当配置，可以实现每一个文件都带有不一样的版本信息。其中hash在webpack编译时动态生成，因此若是经过hash去命名资源文件，全部生成的静态文件会共享同一个hash。而chunkhash是根据chunk内容生成hash，因此chunkhash够实现不一样文件不一样hash的目标。而contenthash，通常只用于ExtractTextPlugin中，如打包css文件而且添加contenthash等。chunkhash打包js代码的问题在于，若是js文件中引用了css模块，每次css模块修改而js自己不作修改的状况下，js文件对应的chunkhash也会被修改，缘由在于默认的chunkhash将引入的css代码也视为该chunk的一部分，不管是更新js代码仍是css代码，都会致使chunkhash的更新。webpack打包时，能够尝试引入webpack-md5-hash解决chunkhash的问题。

版本信息的位置

对于静态资源来讲，版本信息通常能够追加到路径、资源名称或者查询参数中。

• 资源路径
  对于大部分的静态文件服务器来讲，资源的URI每每能够映射到服务器上的特定磁盘路径。基于版本号的请求路径，能够在文件系统中建立以版本号命名的目录，而且拷贝静态资源到该目录中。这样作带来的好处在于，每一个版本都是单独的目录，版本间作到互不影响。弊端也显而易见：部分没有改变的静态资源也会由于路径名的变换而没法实现缓存。

• 资源名称
  将版本信息添加到文件名上意味着打包过程当中，须要重命名静态资源文件，可是不须要建立新的目录，全部的静态文件放在同一目录下。基于文件内容产生的hash做为文件名，可以作到内容不变的静态文件的请求URI也不会发生变化。

• 查询参数
  jQuery disable cache以后，GET方式请求资源的时候会在路径中添加时间戳信息即属于这种。将版本信息追加到查询参数中，与追加到资源名称中相似，不一样的地方在于资源名称不会发生变化，可能会致使不一样版本间的文件相互覆盖，因此须要在发布以前将当前已存在的资源作备份。

npm下的版本管理

npm在前端开发中使用的愈来愈多。npm的版本管理是基于semver实现的，包的版本应该包含主版本号、次版本号和修订版本号。经过~, ^以及<、>等约定使用的版本范围。

不管是在npm2仍是npm3中，同一个包的不一样版本也可以被很好的兼容，不一样版本的包会被安装到各自的路径之下，而且在require/import过程当中调用特定版本的npm包。但其中也有一些例外，一些约定了peerDependencies的npm包，每每须要特定版本的兼容，而且这些版本是排他的，即出现其余版本时，npm install过程当中会出现警告。

npm多层级的依赖关系可能会带来另一个问题：只能将直接依赖的npm包写在package.json中，而没法约定这些依赖自身所依赖的包，也没法肯定其中的版本信息。为了固定整个依赖关系的版本信息，npm提供了npm shrinkwap的功能。npm shrinkwrap经过将完整的依赖版本信息输出到npm-shrinkwrap.json文件中。在此后的npm install过程当中，npm会优先查找而且安装npm-shrinkwrap.json文件中的依赖内容。npm shrinkwrap应该项目起始阶段就应用到项目中，而且在新的依赖添加以后，不断更新。