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

软件开发和发布过程中，版本是个极其重要的因素。大至操作系统，小到功能组件，都会涉及到版本相关的问题。本文主要讨论了静态资源的版本管理，以及前端开发使用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应该项目起始阶段就应用到项目中，并且在新的依赖添加之后，不断更新。