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用起来吧！