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是什么東西呢？