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