How to summarize using Coffeescript in a node. JS Project

Coffeescript as a low-key JavaScript little brother is really a big thing, using it to improve development efficiency, reduce code errors, the key is to greatly enhance the development of pleasure. It is more and more that I find it possible to use coffee in my own projects.

But maybe you're just like me, and when you're ready to try your hand at Coffeescript's grammar, you're worried about how to bring it into the project.

In fact coffeescript this language because it can be one-to-one translation into JavaScript features, use is actually very flexible. There is more than one way to bring it into the project. Here, I'll summarize the way node projects are introduced into Coffeescript, and compare the pros and cons of each approach.

Run a pure Coffeescript project directly using the coffee directive

Generally mention Coffeescript, naturally think he is a JavaScript brother, always out of the shadow of JS. You can actually think of it as a separate language. We all know that after the global installation of the Coffee-script package on the node platform, you can go through the coffee instruction to enter the Coffeescript interface, call it REPL also line. If your project is written entirely in coffee, it's easy to use the coffee command directly on your portal script, such as "App.coffee" for your entry pin, then execute:

coffee app.coffee

Note that the extension coffee here cannot be omitted.

This method should be said to be the most "official" way to use Coffeescript. Simple, Direct! Moreover, once you use a coffee file as the entry point for the project, the whole project is compatible with both coffee and JS. You can arbitrarily require JS or coffee files and modules in the project, and can even require coffee files in the JS files in the project. And when you reference either coffee or JS file without the extension, as long as the previous part of the name does not conflict on the line.

One of the biggest problems with this approach is that if it is a module, it can only be used for coffee projects; If he is an application, the operating environment must have Coffee-script installed. After all, Coffeescript is still a small language, it as a module lost JS user is a pity.

Another possible disadvantage is performance, after all, node inside only JS engine, coffee code needs to compile to JS and then run, the process is to consume a little time, although the coffee to JS compile speed is actually very fast. But this should not be a big problem, generally speaking, require are written at the top of the file, that is, the application at the start of the require of the files are require, require when coffee was compiled into JS put into the JS engine, Then the time that the compilation consumes is focused on when the application starts, the runtime will hardly encounter require new coffee situation. The most common usage scenario for node is the Web server, which is even more problematic.

Referencing Coffeescript in a JavaScript project

The Coffee-script in NPM can be installed either globally or as a module of a project. What is the point of Coffee-script as a module of the project? In fact, a coffeescript compiler is added to the project, and the project can compile the coffee file at any time at run time.

You must want to refer to the coffee file as you would in the first way. No problem, just sign up. If your project entry file is App.js, then you just need to add this to the front of the file:

require(‘coffee-script/register‘);

Then you can require the coffee file in the project.

This approach is essentially not the same as the first, but Coffee-script is not installed in the global, so your module can exist independently, as the application does not need the environment to install the Coffee-script.

Shortcomings, I think the biggest problem is easy to make the code a little messy, a moment js, a while coffee, of course, the first way may also be so, but all with coffee start the inside should not write JS it ... In short I think a project or to unify the language is better (unfortunately, I mainly use this way, in a has been using JS to write the general structure of the project, I would like to use coffee swollen do ... ）

Performance issues are the same as in the first way, not much.

The Orthodox way--compiling

When it comes to compiling, it feels like it's back in the serious C or Java era. Indeed, as a compiled language, it is the right path to compile and run. c There are Gcc,java Javac,cofee have coffee-c.

To compile a cofee file is simple, for example, to edit the App.coffee file, execute it in the current directory of the file:

coffee -c app.coffee

A file named App.js appears in the current directory. This command can also be applied to a directory, such as when you put all the coffee source files in the project into the SRC directory, then execute:

coffee -c src

All coffee source files in the SRC directory and its sub-directories will be compiled into a JS file and placed in the same directory as the source file.

However, for large projects, it is not very good to put the source files together with the compiled result files. Specifying an Output directory is OK:

coffee -c -o outputs src

The order of the parameters of this directive is somewhat strange. This is defined in the help of coffee:

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

Note that all options are between the coffee and the file path. The final args are the parameters that are passed to the target file as the script executes. This means that all options are placed between the coffee and the file name. And-c This option is separate, without its own parameters, it only means that the last side of the command to provide the file to compile, so write this also line:

coffee -o outputs -c src

If you want to add another option, let the compilation result not be surrounded by the self-executing function body, that is:

coffee -o outputs -c -b src

If you want to compile all the source files into a target file named Out.js, it is:

coffee -o outputs -c -j out src

It's annoying to have to execute instructions like this every time Pity Dorado code. The coffee directive has an option-W to monitor changes to the source file and automatically compile:

coffee -o outputs -c -w src

For large projects, it's a good idea to set up a compilation in advance so that all developers need only one instruction to do all the compiling, which requires an automated build.

Offee provides an automated build tool, cake, just like the C world make. But as the official web says, cake is a very simple build system. In fact, the function of cake is to execute a script named Cakefile, and Cakefile script is written in Coffeescript. This script only provides a very limited set of built-in functions, such as task, to declare an instruction and its corresponding description and execution function. The other thing is to write a purely node project that compiles either a string compiled using the FS module of node or the output of the coffee module, or executes the shell instruction with the Child_process module. In fact, the goal of cake construction does not have to be coffee, because it is actually executing a node script that handles any automated things.

There are also some better third-party automation building tools can also complete coffee automatic compilation, such as the famous grunt, as well as the domestic fekit and so on.

This Orthodox compilation may seem the most reliable and should be loved by older programmers. It allows the team to form a fixed development model. In addition, the compiled project becomes a pure JS project, whether it is to run as an application directly or as a module by other project references do not require additional dependencies. And there is no need to compile at run time, there is no performance problem caused by the compilation at all.

The disadvantage is that it is too troublesome. If you are going to do a less-than-large project, cakefile or configuring grunt will cost half a day, not worth it.

Last Words

Summing up the content, I want to tell you that the use of Coffeescript in the node project can be very simple. So, let's get coffee up!

How to summarize using Coffeescript in a node. JS Project