使用coffeescript編寫node.js專案的方法總結_javascript技巧

Node.js 是基於JavaScript編寫應用，JavaScript是我的主要開發語言。 CoffeeScript是編譯為JavaScript的程式語言。其實CoffeeScript語言因其可以一對一的翻譯為JavaScript的特性，使用起來也非常靈活。將其引入專案的方式也有很多種，在此，我將使用coffeescript編寫node.js專案的方法做一個總結。

直接使用coffee指令執行純coffeescript專案
一般提起coffeescript，自然而然地會想到他是javascript的小弟，總脫離不了js的陰影。其實你完全可以把它認定為獨立的語言。 我們都知道，在node平台上全域安裝完coffee-script包後，就可以透過coffee指令進入coffeescript的互動介面， 叫它repl也行。如果你的專案完全是用coffee寫的，那就簡單了，直接對你的入口腳本使用coffee指令就結了， 例如你的入口腳本名為“app.coffee”，那就執行：

請注意，這裡的副檔名coffee是不能省略的。

這個方式應該說是使用coffeescript最「官方」的方式。簡單，直接！而且，一旦你以一個coffee檔案作為專案的入口， 那整個專案就同時相容coffee和js了。你在專案裡可以任意require js或coffee檔案及模組， 甚至可以在專案中的js檔案中隨便require coffee檔案。而且在你引用無論是coffee或js檔案的時候都不需要副檔名， 只要前面部分名稱不衝突就行。

這個方式有個最大的問題就是，如果它作為一個模組，只能被用於coffee專案；如果他作為一個應用， 運行環境必須安裝coffee-script。畢竟coffeescript現在還是小眾語言，它作為模組時失去了js用戶實在可惜。

另一個也許存在的缺點是效能方面的，畢竟node裡面只有js引擎，coffee程式碼需要先編譯為js再運行， 這個過程是要消耗一點點時間的，儘管coffee到js的編譯速度其實挺快的。不過這應該不是什麼大問題， 一般來說，require都是寫在文件的頂部，也就是應用在啟動的時候就一氣兒把該require的文件都require了， require的時候coffee就被編譯成了js放到了js引擎中，那麼編譯消耗的那點時間都集中在了應用啟動時， 運行時幾乎不會遇到require新的coffee的情況了。 node最常見的使用場景是web伺服器，這就更沒問題了。

在javascript專案中引用coffeescript
npm中的coffee-script既可以全域安裝，也可以作為專案的一個模組安裝。那coffee-script作為專案的一個模組有啥意義呢？ 其實是為專案增加了一個coffeescript的編譯器，這個專案就可以在執行時隨時編譯coffee檔。

你一定希望像第一種方式裡那樣隨便引用coffee檔。沒問題，只要註冊一下。假如你的專案入口檔案是app.js， 那麼只需要在這個檔案最前面加上這麼一句：

然後你就可以在專案中隨便require coffee文件了。

這個方式本質上和第一種方式沒啥區別，只不過coffee-script沒安裝在全局，因此你的模組可以獨立存在， 作為應用也不需要環境安裝好coffee-script了。

缺點嘛，我覺得最大的問題就是容易讓程式碼有些亂，一會兒js，一會兒coffee，當然第一種方式也可能會這樣， 不過都用coffee啟動了裡面應該不會寫js了吧…總之我覺得一個專案還是把語言統一起來比較好（遺憾的是我主要用這種方式，在一個已經用js寫出了大體結構的專案裡，我就想用coffee腫麼辦…）

效能問題上跟第一種方式一樣，不多說了。

正統的方式——編譯
一說編譯，就感覺回到了正兒八經的C或Java的時代。的確，作為一個編譯型語言，編譯後再運行才是正道。 c有gcc，java有javac，cofee有coffee -c。

要編譯一個cofee文件很簡單，例如要編輯app.coffee這個文件，就在文件的目前目錄執行：

一個名為app.js的檔案就出現在目前目錄下了。這個指令也可以應用在目錄， 例如你把專案中所有的coffee原始檔放到了src目錄下，那就執行：

src目錄及其各級子目錄下的所有coffee原始檔都會編譯成js文件，放到和原始檔相同的目錄。

不過對於大型項目，把原始檔和編譯結果檔放到一起可不太好。指定一個輸出目錄就行了：

這個指令的參數順序有點奇怪。在coffee的幫助裡是這麼定義的：

注意，所有的選項（options）都在coffee和檔案路徑之間。而最後的args是把目標檔案當作腳本執行時給傳遞的參數。 也就是說所有的選項都放在coffee和檔名之間就可以了。 而-c這個選項是單獨的，沒有自己的參數，它只表示要把指令最後面提供的那個檔案給編譯了，所以寫成這樣也行：

假如想再加個選項，讓編譯結果不被自執行函數體包圍，就是：

再假如想把所有原始檔編譯成一個名為out.js的目標文件，就是：

如果每次改點程式碼都要這麼執行指令也挺煩人的。 coffee指令有一個選項-w可以監視原始檔的變動而自動編譯：

對於大型專案來說，最好事先確定好編譯方式，讓所有開發人員只需要一個指令就搞定所有編譯的事情，這就需要自動化建置了。

offee提供了一個自動化建置工具，cake，就像c世界的make。 不過就像官網上說的那樣，cake是一個很簡單的建置系統。其實cake的功能就是執行一個名為cakefile的腳本， 而cakefile腳本是用coffeescript寫的。這個腳本只提供非常有限的內建函數，例如task， 用來宣告一個指令及其對應的描述和執行函數。其它的就是在寫一個純粹的node項目， 想完成編譯或使用node的fs模組輸出coffee模組編譯出來的字串， 要嘛用child_process模組來執行shell指令。其實cake建置的目標不一定必須是coffee，由於它實際上是執行一個node腳本， 處理任何自動化的事情都可以。

另外還有一些更優秀的第三方自動化建置工具也可以完成coffee的自動編譯，例如著名的Grunt，以及國內的fekit等。

這種正統的編譯方式也許是看起來最可靠的，應該深受老程式設計師的喜愛。它可以讓團隊形成固定的開發模式。 另外，編譯後的專案就成了純的js項目，無論是作為應用程式直接運作還是作為模組被別的項目引用都不需要額外的依賴。 而且執行時間不需要編譯，也就完全不存在編譯導致的效能問題了。

缺點嘛，就是太麻煩。如果你要做一個不太大的項目，光搞cakefile或設定grunt就要花半天時間，不太值得。

 透過以上內容總結，其實在使用coffeescript寫node.js專案可以非常簡單，接下來希望大家抓緊把coffee用起來。同時也希望以上內容對大家有幫助。