This package has been deprecated
this package is not maintained anymore
Mix in node's require, some angular dependency injection look&feel and the ease of use of RequireJS and what do you get?
Dependency injection done right for Node.js!
Since 0.6.0 module's isolation at load time has been reworked to be optional and deactivated by default instead of enforced on all loaded modules. Please be careful when upgrading.
In general, be careful when upgrading before 1.0.0 is released. Carefully review changelog. Minor changes (last digit in version number) can be considered safe though.
npm install r42
// path & fs are examples to show you how to load node modules// _ will contain lodash (see next section to see why);
var r42 = ;var path = ;var context = r42;// Let's get startedcontext;
Module names can handle any characters that are allowed in a path since they are derived from file names except dot (
.) and exclamation mark (
!) which are reserved by r42.
We also strongly advise you not to use characters forbidden in Windows file system (eg
: < > " \ | ? *). For a full list of those, you can refer to this MSDN page.
A good (best) practice would be to only use english alphanumeric characters
[a-zA-Z0-9] without any special character. You might include
_ if you are a snake case adept but it's more C like than JS like. I would rather recommend using camel case because it's going to look nicer in your code.
If you want to resolve complex names in subdirectories, you can use the optional
replacer argument of the define function. Here is an example:
The object maps an argument's name to the real module name locally. The argument name will be replaced by the given module name before injection happens.
You can also use special r42 comments (looking like
/*! module */) before your argument names:
Note : spaces are optional in r42 comments.
Sometimes, it is a pain to refer to a module in the same folder as you are right now. r42 allows for a fine way to do so.
$ to prefix your variable's name will automatically cause r42 to replace it by your current module's "path". It also works to prefix files in the
In a module
You can refer to an index module using only the folder's name just like so:
And in a file at the same level as folder:
r42 supports requiring only part of a module by using the dot (
.) notation just like in this example:
As you can also see in the above example, the dot notation is not restricted to a single level in the module. You can look for nested properties as deep as you want.
Please note that there is no array notation allowing you to access properties in an array using the  operator.
Since the dot notation is reserved to load subproperties (see above), you need to alias modules in your r42 config.pahs to load such modules. Here is an example:
var r42 = ;var context = r42;// Let's get startedcontext;
Those are working "automatically" but you NEED to exports barebone objects on both modules for it to work.
Here is an example:
In a module
In a module
r42 also supports the Require.js
exports notation. It is very useful when you might want to replace an exported function of a module by another to spy on it (in tests sequences for example). It might also be used to support circular dependencies. When you do not use
exports, r42 copies everything you return into the object it presented to other dependencies. This is slower and might cause bugs that
exports would not create.
Here is an example of a compatible module for exporting values using
exports is also accessible without injection using
Exporting primitives is usually not possible to do if you also need this module to work in a circular dependency model. To circumvent this, the easiest solution is to export the primitive in a subproperty of your module like so:
This is working well in most cases. The only thing to ensure is not to use the value in the module definition itself but only in exported codebase:
Returning primitives is dangerous but is easier to use. Thus, sometimes, you might prefer to do it. r42 will protect you if you tell him what you are doing explicitely:
In this case, if someDep becomes circular at any point, r42 will throw an error preventing us to do so. This is the recommended way to export primives.
Do not use the dot notation when accessing a subproperty of a circular dependency This is basically the same as using the primive in the module definition. Currently it will fail silently. A safeguard will be added in the future.
r42 allows you to create your own loading modules & to load modules using a different policy than its own. By default, a require load mechanism & a json load mechanism are included by default in r42.
To use a different load mechanism than the default one, you need to prefix its name by
json!module). This implies that you have to use the
replacer argument or r42 comments to load a plugin using a specific loader.
With the json loader:
With the require loader:
Sometimes some modules (often npm libraries) are singletons. That can cause a lot of problems when they are used by both you and one of your dependencies because you might not want to use the same configuration on it. Because code will be shared as an optimization by npm, it can cause headaches to solve this situation.
r42 provide a way to partially negate this problem. It is called
isolation. This mechanism allows you to ask r42 to clean the module and its dependencies from the require's cache after loading them. Like that, any other require on them will create a brand new RAM instance of the library.
To use isolation, you just have to fill properly the
isolate configuration variable like so:
Because your dependencies are probably not properly cleaning behind them singletons (everyone is not using r42 ^^), to ensure no problem arise, you should also make certain your isolated modules are loaded before the dependencies that use them.
Since r42 is synchronous, you can easily find out in which order a module is loaded.
// BAD orderr42;// GOOD orderr42;
As a special note: open bugs on the dependencies that do not clean singletons asking them to do so. It will allow you to never again think about the correct order to load modules. This should not be important (and is not in a full r42 environment properly configured).
Important note: if you isolate a module,
instanceof and such keywords won't work between instances of each isolated module (which might be good or bad depending on your use cases) and this might lead to strange bugs. Use with caution. Example :
You can also use r42.inject to load modules dynamically. In this case, provide a module name or module list and optionally a
replacer as usual. Here is what it could look like:
There is a test API that is intended to help writing tests & speed up tests by preventing a module to be reloaded more than necessary. This API is accessible when the
NODE_ENV environment variable is set to
"test" or by passing "test" as a first argument to the
createSub method as demonstrated below:
var context = /* create here as you want a r42 context with normal paths */var subContext = context;// now subContext can be used just as context and inherits its configurationsubContext;
You can write other loader plugins and register them to r42 to use them after that in your codebase. Here is how to do so:
var r42 = ;var path = ;var fs = ;var myYamlModule = ;r42;
This function might be useful to gather information about your module & to debug dependencies problems. It takes an
options parameter which is an object that can take the following two options:
true): whether to colorize the output or not
true): whether to print to stdout automatically the result or not
colors option requires that you install
chalk (version >=0.4.0) as a dependency of your project.
It returns a string containing the dependencies information.
var r42 = ;var context = r42;// Let's get startedcontext;
Since version 0.0.21, r42 has been rewritten to be completely synchronous. This means that you can use it easily, even to create library packages. Here is a simple example of what your main library file might look like :
var r42 = ;var context = r42;context;
Since your library uses r42, you have to take into account the fact that a module depending on your code also uses it. If the versions required by your module and its dependant are compatible, they will share the r42 codebase. This means that r42 will be installed in a parent
node_modules folder. If nothing is done, it will break
require in your r42. To prevent this from happening,
you HAVE TO add the
require configuration variable to your configuration (in the same way as in the previous example).
- update dependencies
- prevent AMD modules to be mixed up in r42 by cleaning env (this might cause strange error messages instead saying define() is undefined)
- update dependencies
- do not show
exports(or modules requiring themselves) as circular dependencies in
r42.exportsPrimitive(path to deprecate most of the return syntax)
returnoptional in modules (prepare for deprecation)
thisin module definitions as an alias to
- fix a bug preventing modules from exporting objects with getters and/or setters
- add support for dot (
.) notation to load only sub properties of a module
- add support for special
- fix regression preventing plugin to be used in r42's
- fix breaking bug in 0.6.0
- do not isolate modules by default
requireconfiguration property (see Using r42 in libraries in the documentation)
pathconfiguration property to contain plugin syntax (e.g:
- Add testing API
- Add plugin API
- Add plugins
- default (previous loading mechanism moved to a plugin)
- require (force use of require, no define expected in module)
- json (load JSON file - using require)
- Remove the beta channel warning that was forgotten
- Make r42 instantiable.
- Clean up related require's cache after loading a module with r42
- Continue work started with 0.2.1 to prepare for 0.3.0
- Change architecture to prepare for 0.3.0 that will change r42 API so that r42 si not a singleton anymore
- Colors dependency was dumped in favor of chalk that does not mess up String's prototype
- small bug fixes
- better readability