淺談前端開發中的版本管理

軟件開發和發佈過程當中，版本是個極其重要的因素。大至操做系統，小到功能組件，都會涉及到版本相關的問題。本文主要討論了靜態資源的版本管理，以及前端開發使用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應該項目起始階段就應用到項目中，而且在新的依賴添加以後，不斷更新。