node.js項目中使用coffeescript的方式彙總

Coffeescript做爲Javascript低調的小弟實在是有過人之處，使用它能夠增進開發效率，減小代碼錯誤， 關鍵是能大幅提高開發愉悅感。我愈來愈以爲只要可能就在本身的項目中把coffee用起來。

然而也許你和我同樣，在瞭解完coffeescript的語法後準備一試身手的時候，卻面對如何把它引入項目而犯起愁來。

其實coffeescript這種語言因其能夠一對一地翻譯爲javascript的特性，使用起來其實很是靈活。 將其引入項目的方式也不止一個。這裏，我先就node項目引入coffeescript的方式做一個彙總，並對比一下各個方式的優劣性。

直接使用coffee指令運行純coffeescript項目

通常提起coffeescript，天然而然地會想到他是javascript的小弟，總脫離不了js的陰影。其實你徹底能夠把它認做是獨立的語言。 咱們都知道，在node平臺上全局安裝完coffee-script包後，就能夠經過coffee指令進入coffeescript的交互界面， 叫它repl也行。若是你的項目徹底是用coffee寫的，那就簡單了，直接對你的入口腳本使用coffee指令就結了， 好比你的入口腳本名爲「app.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-script/register');

而後你就能夠在項目中隨便require coffee文件了。

這個方式本質上和第一種方式沒啥區別，只不過coffee-script沒安裝在全局，所以你的模塊能夠獨立存在， 做爲應用也不須要環境安裝好coffee-script了。

缺點嘛，我以爲最大的問題就是容易讓代碼有些亂，一下子js，一下子coffee，固然第一種方式也可能會這樣， 不過都用coffee啓動了裏面應該不會寫js了吧……總之我以爲一個項目仍是把語言統一塊兒來比較好 （遺憾的是我主要用這種方式，在一個已經用js寫出了大致結構的項目裏，我就想用coffee腫麼辦……）

性能問題上跟第一種方式同樣，很少說了。

正統的方式——編譯

一說編譯，就感受回到了正兒八經的C或Java的時代。的確，做爲一個編譯型語言，編譯後再運行纔是正道。 c有gcc，java有javac，cofee有coffee -c。

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

coffee -c app.coffee

一個名爲app.js的文件就出如今當前目錄下了。這個指令也能夠應用於目錄， 好比你把項目中全部的coffee源文件放到了src目錄下，那就執行：

coffee -c src

src目錄及其各級子目錄下的全部coffee源文件都會編譯成js文件，放到和源文件相同的目錄中。

不過對於大型項目，把源文件和編譯結果文件放到一塊兒可不太好。指定一個輸出目錄就好了：

coffee -c -o outputs src

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

coffee [options] path/to/script.coffee -- [args]

注意，全部的選項（options）都在coffee和文件路徑之間。而最後的args是把目標文件做爲腳本執行時給傳遞的參數。 也就是說全部的選項都放在coffee和文件名之間就能夠了。 而-c這個選項是單獨的，沒有本身的參數，它只表示要把指令最後面提供的那個文件給編譯了，因此寫成這樣也行：

coffee -o outputs -c src

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

coffee -o outputs -c -b src

再假如想把全部源文件編譯成一個名爲out.js的目標文件，就是：

coffee -o outputs -c -j out src

若是每次改點代碼都要這麼執行指令也挺煩人的。coffee指令有一個選項-w能夠監視源文件的變更而自動編譯：

coffee -o outputs -c -w src

對於大型項目來講，最好提早肯定好編譯方式，讓全部開發人員只須要一個指令就搞定全部編譯的事情，這就須要自動化構建了。

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就要費半天時間，不太值得。

最後的話

總結了這些內容，其實就是想告訴你在node項目中使用coffeescript能夠很是簡單。那麼，就趕忙把coffee用起來吧！