摘要：可發布這一部分會在下一章管理對子項目引用中詳細說明。總結本文總結了多項目共享子項目工程化方面的一些實踐，并不涉及到復雜的代碼，主要涉及到的概念，使用進行包管理，使用作為自動化工具等工程化的知識。

公司的產品線涵蓋多個產品，這些產品中會有一些相同的功能，如登錄，認證等，為了保持這些功能在各個產品中的一致性，我們在各個產品中維護一份相同的代碼。這帶來了很大的不便：當出現新的需求時，不得不同時在多個產品中更改代碼，使它們保持一致。為了解決這個問題，我們可以將這些公共部分抽取出來放在一個多帶帶的子項目中，其他項目只是引用該子項目，當出現新的需求時，我們只要改變該子項目即可。

在這個思路的基礎上，有兩個問題需要解決:

以何種方式維護子項目

如何維護產品對子項目的引用

我們先從一個正常的angular項目說起。例如，如果你想在你的項目中引入Angular UI Bootstrap組件，通常你會怎么做？

在bower.json中添加所需要的dependencies:

{
  "name": "your project",
  "version": "0.0.1",
  "dependencies": {
    "angularJS": "1.4.x",
    "angular-animate": "1.4.x",
    ....
  }
}

使用bower install命令，安裝dependencies，并引用:

在你的項目中聲明dependencies：

angular.module("myModule", ["ui.bootstrap"]);

通過以上的例子我們可以得到一定的啟示:

子項目最終應該以angular module的形式出現

使用bower去維護對包的引用

可配置，當使用該模塊時可以對該模塊傳遞參數

可構建，將分離的多個文件構建成一個文件

可測試，保證模塊的魯棒性

可發布，供其他項目引用

包含完整的事例代碼，供其他人參考

我們在代碼層面上可以通過provider來實現。例如：

angular.module("myModule")
    .provider("myProvider", function() {
        var name = null;
        
        // setName can be called duaring module init
        this.setName = function (newName) {
            name = newName;
        }; 
        
        return {
            handleName : function() {
            // do something with name
            }
        };
    })

在另一個module中引入該module時，我們可以改變該module中name的值:

angular.module("anotherModule", ["myModule"])
    .config(function(myProviderProvider){
        myProviderProvider.setName("name");
    });

provider是模塊之間交流的橋梁，它可以使模塊達到可配置。

在angular中，一個模塊的本質就是一個命名空間，在該命名空間中我們可以增加provider, directive, factory, constant等，它實際上就是一個功能的集合。聲明形式通常如下:

angular.module("myModule", [dependencies])
    .directive("myDirective", ...)
    .factory("myFactory", ...);
    ...

directive是angular中最重要的概念，它是angular 1.x中實現組件化的基礎。factory通常是為了完成一些輔助功能，如與后端進行數據交互或提供一些util方法等。但是為了代碼的可維護性，通常它們會將它們放在一個多帶帶的文件中, 如:

file1.js為模塊的聲明文件:

angular.module("myModule", [dependencies]);

file2.js為一個directive聲明文件:

angular.module("myModule")
    .directive("mydirective", function() {
        ...
    });

file2.js為一個factory的聲明文件:

angular.module("myModule")
    .factory("myfactory", function() {
        ...
    });

但是在發布版本中，我們希望所有的這些文件合并在同一個js文件中，這就是構建的過程。我們可以使用gulp構建工具實現該目的。directive中有時會包含模板html文件，我們將html文件通過angular的$templateCache服務也打包進js中。

通常前端的測試分為兩種: 單元測試和集成測試(又叫做E2E測試)。單元測試的目的是為了測試一個接口或者功能是否能得到預期的結果，測試對象通常為一個函數，但是前端最大的問題就是瀏覽器的兼容問題，可能在一個瀏覽器中能跑的代碼在另一個瀏覽器中出現錯誤，所以我們需要在多個瀏覽器中去進行測試，我們可以使用gulp搭配測試框架karma去簡單的完成在多瀏覽器下的單元測試。集成測試是站在用戶的角度上去執行各種操作，看產品是否穩定等。由于該模塊中只是出現一些簡單的UI組件，并非一個完整的產品，所以并沒有做相關的集成測試。

這一部分會在下一章bower管理對子項目引用中詳細說明。

由于模塊會在多個項目中被不同的人使用，對于這些人最快熟悉該模塊的方法就是通過一些demo去了解，所以每個模塊中應該包含一定的事例代碼供模塊的使用者參考。

目錄結構如下:

javascript-modules
    - module1
        - lib
            - myproject.module.js
            - component
                - mydirective.directive.js
                - template.html
                - templateStyle.scss
            - myfactory.factory.js
            - myprovider.provider.js
            - ....spec.js
            ...
        - release
            - myproject.bundle.js
            - myproject.bundle.css
        - example
            - example1
            - example2
    - gulp
        - task1.js
        - task2.js
        ...
    - gulpfile.js
    - karma.js
    - package.json

說明:

lib: 源代碼目錄

release: 發布版本目錄(只包括js和css文件)

example: 事例代碼目錄，具體的事例代碼目錄下包含index.html文件，在該html文件中引入release版本的js和css，然后啟動http-server命令打開本地服務器進行測試

gulp: gulp task目錄

gulpfile.js: 用于執行gulp目錄中的各種task

karma.js: karma配置文件

package.json: 配置文件

gulp中應包含以下task:

build: 合并所有的html文件到$templateCache中，合并所有的js文件，將scss等編譯成css

test: 執行lib下的所有測試文件

release: 將打包后的最終代碼上傳到內部包管理服務器等

PS: 由于歷史遺留問題，angular中component和directive之間的界限模糊不清。指令應只封裝DOM操作，而組件代表一個自給自足的獨立單元 - 有自己的視圖和數據邏輯。在angular1.5中增加了component的概念，我們應該更加清晰的區別component和directive，在使用時directive只應該執行封裝DOM的操作，而不應該去創造DOM節點，也就是說directive中的restrict應設置為A。

模塊版本發布應遵循semver(語義化版本)原則。
版本格式為:主版本號.次版本號.修訂號(MAJOR.MINOR.PATCH)。版本號遞增規則如下：

主版本號：當你做了不兼容的API修改，

次版本號：當你做了向下兼容的功能性新增，

修訂號：當你做了向下兼容的問題修正。
版本號的管理應該包含在gulp release任務中。

通常我們希望我們開發出的模塊只是對企業內部可見，對外部不可見。這就要求我們不能使用平常的方式去使用bower進行包的發布和依賴管理。在借鑒了后端的一些包管理思路后，我們將該包發布在企業內部的私有包管理服務器上，然后在bower.json中通過以下方式來引入包:

{
    "module":"address/module-version.zip"
}

每次當有新的版本的包發布時，我們只需要在bower.json中改變version號，然后使用bower install重新安裝新版本的包即可達到更新包的目的。

本文總結了angular 1.x多項目共享子項目工程化方面的一些實踐，并不涉及到復雜的代碼，主要涉及到angular module的概念，使用bower進行包管理，使用gulp作為自動化工具等工程化的知識。
上述方法也存在一定的問題，每次版本更新時，都要在引用它的各個項目中更新版本號并使用bower install重新安裝該模塊。
一種更好的思路是使用git submodule/subtree，由于并沒有在這方面的實踐經驗，所以不再贅述。
本文主要是針對angular1.x版本的實踐。由于當前angular2已經發布，它提供了強大的組件功能，所以針對angular2會有更好的組件化方式實現。