There is well known Lisp joke:
A top hacker successfully stole the last 100 lines of a top secret program from the Pentagon. Because the program is written in Lisp, so the stolen code is just close brackets.
It is a joke that there are too many brackets in Lisp. In Node.js there is a similar issue that there are too many
require. Open any node.js file, usually one could find several lines of
Due to the node’s sandbox model, the developer has to require resources time and time again in every files. It is not so exciting to write or read lines of meaningless
require. And the worst, it could be a nightmare once a developer wishes to replace some library with another.
“Require hell” isn’t only for node.js, but also for Ruby apps. Rails has solved it gracefully, and the developer barely needs to require anything manually in Rails.
There are 2 kinds of dependencies in rails app, one is the external resource, another is the internal resource.
External resources are classes encapsulated in ruby gems. In ruby application, developer describe the dependencies in
Gemfile, and load them with
Bundler. Some frameworks have already integrated with
Bundler, such as Rails. When using them, developer doesn’t need to do anything manually, all the dependencies are required automatically. For others, use
bundle execute to create the ruby runtime with all gems required.
Internal Resources are the classes declared in the app, they could be models, the services or the controllers. Rails uses
Railtie to require them automatically. The resource is loaded the first time it is used, the requiring process is “Lazy”. (In fact, this description isn’t that precise because Rails behaves differently in production environment. It loads all the classes during the launching for performance reason).
Rails avoids the “require-hell” with two “autoload” mechanisms. Although there are still debates about whether autoload is good or not. But at least, autoload frees the developer from the dull dependency management and increases the productivity of developers. Developers love autoload in most cases.
So to avoid “require-hell” in Node.js, I prefers autoload mechanism. But because there are significant differences in type system between Node.js and Ruby, we cannot copy the mechanism from ruby to node as is. Therefore before diving into the solution, we need to understand the differences first.
There are a number of similarities between Node.js and ruby; things in node.js usually have the equivalences in ruby. For example,
package in node is similar to the
gem in Ruby,
npm equals to
package.json takes the responsibility of
Gemfile.lock. The similarity enables porting autoload from ruby to node.
In some aspect, there are similarities between Node.js and Ruby, but there are also significant differences between them in some other aspects. One of the major differences is the type system and module sandbox in Node.js, which works in a quite different way to Ruby type system.
In ruby, it is a lot better. With the help of the well designed type system, types are shared all over the runtime, a developer just needs to require the types not yet loaded.
So in node.js programs, there are many more
In fact, with the help of JSLint, CoffeScript and some other tools, developers can avoid global leak easily. And global sharing isn’t the source of evil. If abuse is avoided, I believes a reasonable level of global sharing could be useful and helpful. Actually Node.js have built-in a global sharing mechanism.
To share values across file, a special variable
global is needed, which could be accessed in every file, and the value of which is also shared across files.
Besides sharing value around,
global has another important feature: node treats
global as default context, whose child you can refer to without explicitly identifying. So
SomeType === global.SomeType.
With the help of
global, we find a way to share types across files naturally.
Rails’ autoload mechanism loads the classes lazily. It only loads the class when it is used for first time. It is a neat feature, and Rails achieve it by tracking the exception of “Uninitialized Constant”. To implement similar feature in Node.js, tracking exception is hardly feasible, so I choose a different approach, I use Property.
require function has built in the cache mechanism; it won’t load the file twice, instead it return the value from its cache.
With property, we make the autoload lazy!
To make autoload work, we need to create a magic host object to hold the type variables. In my implementation, I call the magic object Autoloader
we need to require a bootstrap script when the app starts, which is used to describe which types and how they should be required.
The script sets-up the autoload hosts for all services, routes, records, models for my app. And we can reference the types as following:
initEnvironment.coffee script, there are 2 very important classes that are used:
- AutoLoader: The class that works as the type variable hosts. All the magic happens here.
- PathHelper: The class used to handle the path combination issue.
The detailed implementation is here:
Besides of the content, I want to say thank you to my English teacher Marina Sarg, who helped me on this series of blog a lot. Without her, there won’t be this series of blogs. Marina, thank you very much.