經過Anuglar Material串串學客戶端開發 - javascript編譯和gulpfile.js

Angular Material不單單有自己框架的源代碼，還有在這個框架上實現的一個應用docs。更爲強大的是，這個應用是真正的產品網站：就是它的官網。我有理由相信，這個網站是從源代碼直接發佈的，從網址的最後那個/latest,咱們能夠看出端倪。

從這個產品自己入手不失爲學習的捷徑。

入口gulpfile.js

C/C#命令行的應用，咱們會尋找Main()方法；C#的Web應用咱們會找Global.asax；那麼一個NodeJS應用咱們就要找gulpfile.js。

注意：之前的不少項目都是用gruntjs，而近期趨勢是轉向gulpjs,我本身的感受也是gulpjs很好理解，性能也不錯。

和前兩個不一樣的是，gulp.js其實不是應用運行的入口，而是項目編譯的入口。gulp就至關於微軟的MSBuild用來定義編譯任務。

Javascript也有編譯

編譯，JS文件還要編譯？是的，若是你對客戶端應用的印象還停留在html文件中直接引用你寫的JS文件，那就已經大大落伍了。至少，不少的javascript的框架項目，如jQuery, AngularJS等等，都有編譯的過程。雖然，這個編譯和咱們編譯型語言（如C，C#等）的編譯技術有些不一樣，可是角色是同樣的：因爲編譯過程的存在，使得咱們的開發環境和產品環境隔離，這種隔離也是一種解耦。

編譯即解耦

解耦帶來的價值就是，咱們能夠自由安排開發時的文件結構，而不要過多考慮產品文件結構的需求。好比：開發時咱們更但願根據模塊和責任的劃分，分別對應不一樣的文件（文件越多越好），而產品階段，則但願內容集中（文件越少越好）。對應這個狀況，javascript就有一個編譯步驟concatenate(合併文件)。從實現技術上看，這沒有什麼神奇的東西，可是這徹底體現了編譯的本質。

兩個gulpfile.js文件

然而，編譯不是Gulp的關鍵詞，Gulp的關鍵詞是任務（task），更多時候我把它和Ant/nAnt對等來看。

回到Angular Material的源代碼來。我發現它竟然有兩個Gulp.js文件。一個在根目錄，另一個docs/gulpfile.js。從這我在瞭解到，他實際上是兩個項目，一個是material框架，另一個是它的官網。它兩部分代碼寫到有一個代碼庫，並且由於它官網自己也使用了material框架，甚至有一部份內容都是從框架中自動生成的，也是爲何寫到一個代碼庫的理由。

然而，兩個編譯文件暴露了它是兩個項目的事實，至少是兩個發佈（發佈和項目的區別？）。 兩個發佈就是兩個產品，又一次印證了編譯是開發和產品的解耦器！

module.exports

然而，第二個編譯文件docs/gulpfile.js中卻看到了一個奇怪的東西module.exports = function(gulp, IS_RELEASE_BUILD) {。

module.exports是什麼東西呢？