Dependency injection done right.
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)define/* Your code goes here */// You can export anything, a scalar, a function, an object, an array...// Objects & functions should be preferredreturn /* what you exports goes here */;;
var r42 = require'r42';var path = require'path';var context = r42config// Sets the root directory in which modules are looked forbaseDir: pathjoin__dirname 'lib'// Allows to map paths / module names to something elsepaths:// _ will load lodash_: 'lodash'// Target paths are all relative to baseDir.// Here "library" will try to load "baseDir + '../vendor/library'"library: '../vendor/library'// Replacement in paths are also possible: here all modules named// 'sub/.../truc' will be looked for into the ../sub foldersub: '../sub'// Alias can also be used in configuration but they HAVE TO be declared// BEFORE being used in the objectshMod: 'sh/module' // refers to 'sh/module'sh: 'shortcut'shMod2: 'sh/module2' // refers to 'shortcut/module2';// Let's get startedcontextinject// you can use your dependency here;
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:
definetest: 'sub/folder/test'// here test will be resolved to module 'sub/folder/test';
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:
define// here test will be resolved to module 'sub/folder/test';
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
definesuperSub: '$super/sub'// superSub refers to 'module/super/sub'// $sideFn refers to module/sideFn// sideVal refers to $sub/sideValue;
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:
define// Here $folder will load folder/index.js;
r42 supports requiring only part of a module by using the dot (
.) notation just like in this example:
define// here myModule.MyObject === MyObject// and myModule.tree.TreeNode === TreeNode;
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 = require'r42';var context = r42configbaseDir: __dirname// Allows to map paths / module names to something elsepaths:myComplexModule: 'my.complex.module';// Let's get startedcontextinject// here myComplexModule will be module 'my.complex.module'// and not the 'complex.module' subproperty of module 'my';
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
define// here b might be empty if it was loaded before a, so don't use itreturn// here b should be fully usablebbFn;;;
In a module
define// here a might be empty if it was loaded before b, so don't use itreturn// here a should be fully usableabFn;;;
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
define// ...;// ...return exports; // optional;
exports is also accessible without injection using
define// ...;// ...;
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:
define// here instead of returning the function, I export it using the object way…// use circularDep in some way;
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:
definemyPrimitiveModulemyPrimitive; // Might fail!myPrimitiveModulemyPrimitive; // OK;
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:
define// we are explicitely exporting this module as a primitivereturn r42exportsPrimitive// use someDep in some way;
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.
define// here myPrimitive can be depending on the module load order:// this is bad so don't do it// See context.dumpDeps() below to find out what your dependency// tree look like
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:
define// Here "config" contains ./config.json parsed into a JS structure;
With the require loader:
define// Here "externalModule" contains the value returned by calling require with// ./externalModule;
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:
r42configpaths:_: 'lodash'// whateverisolate:'_' // you can use aliases or full module names here (npm or local)'json!package' // you can also refer to modules loaded by pluginsyour plugin needs to support isolation;
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 orderr42configisolate: 'i18next'inject// this is bad because here i18next will be loaded in require.cache before// r42 can load i18next thus it will already be in cache and there will be// nothing to clean;// GOOD orderr42configisolate: 'i18next'inject// this is good because r42 will load i18next and store it in its internal cache// then it will clean r42 from require's cache allowing your dependency to find// a clean cache and to load it from scratch again;
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 :
r42config/*...*/injectvar isolated2 = require'isolated';var a = ;a instanceof isolatedMyObject; // truea instanceof isolated2MyObject; // false// this is so because isolated2.MyObject is a different function containing the// exact same code than isolated.MyObject, so they are not stricly equal (===)isolated !== isolated2 // trueisolatedMyObject !== isolatedMyObject // true;
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:
define// This will load lodash in variable _.var _ = r42inject'lodash';// Same thing for the variable alias but using the replacer argument.var alias = r42inject alias: 'lodash' 'alias';// An example with multiple load at once// Here modules will resolve to require('util')// and modules to require('net')var modules = r42inject'util' 'net';// You can also use the replacer argument with an array:// this example will load the same modules as the previous onemodules = r42injecta: 'util' b: 'net' 'a' 'b';;
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 = contextcreateSub"test" // this argument can be omitted if process.env.NODE_ENV="test"paths:moduleToMockup: 'mockupModule';// now subContext can be used just as context and inherits its configurationsubContextinject/* inject as usual */;
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 = require'r42';var path = require'path';var fs = require'fs';var myYamlModule = require'myYamlModule';r42registerLoader'yaml'// moduleDef contains information about the module that should be loaded// parent contains information about the module that required moduleDef// mc is the context object, it handles the modules' cache// mc.$baseDir is the root path of the project// moduleDef.name contains the path to the module from baseDir// (without any extension)var filePath = pathjoinmc$baseDir moduleDefname + '.yaml';try// The loading should be synchronousvar yaml = fsreadFileSyncfilePath 'utf8';yaml = myYamlModuleparseyaml;// Init the module into the contextmcinitModulemoduleDef yaml;catch e// <module>.fullName contains the plugin's name + ! + the module's nameemessage = '[r42:yaml] Cannot load module ' + moduleDeffullName +' (required by module ' + parentfullName + '): ' + emessage;throw e;;
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 = require'r42';var context = r42config// Your config HERE;// Let's get startedcontextinject// Dump dependencies with colors using process.stdout.printcontextdumpDeps;// This verion will return you the string without any colors and without printing it :var depstr = contextdumpDepscolors: false // Do not use term colors in the output stringprint: false // Do not print the string on stdout;// Now you can do whatever you want with the string, like send it over network...;
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 = require'r42';var context = r42configrequire: require/* Other configuration properties */;contextinjectmoduleexports =// Whatever;;
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).
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