Version 0.4.0

LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) analog-nico
+Copyright (c) Nicolai Kamenzky (https://github.com/analog-nico)
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of
 this software and associated documentation files (the "Software"), to deal in

README.md

@@ -59,7 +59,7 @@ I have to admit by implementing my own dependency injector I have the advantage
 This module is installed via npm:
 
 ``` bash
-$ npm install fire-up
+$ npm install fire-up --save
 ```
 
 ## Getting Started
@@ -559,10 +559,12 @@ As expected from a dependency injection container the way to instantiate modules
 
 ### Migrating your existing node.js app to Fire Up!
 
-If you have a large node.js app that doesn't use a dependency injector yet or does use another one you certainly do not have the option to rewrite your whole app to use Fire Up! at once. Fortunately, Fire Up! does not enforce an all-or-nothing approach. You can just migrate a small area of your app and use an injector for instantiating the code in just that area. It is even possible that the migrated modules still use regular require calls.
+If you have a large node.js app that doesn't use a dependency injector yet or does use another one you certainly won't have the option to rewrite your whole app to use Fire Up! at once. Fortunately, Fire Up! does not enforce an all-or-nothing approach. You can just migrate a small area of your app and use an injector for instantiating the code in just that area. It is even possible that the migrated modules still use regular require calls.
 
 If you use a hybrid approach where you just use Fire Up! for certain areas of your app you should, however, pay attention to the modules' singleton nature: In traditional node.js development you are used to getting a singleton instance of a module when you require it. Fire Up! retains that singleton nature per default. For that a Fire Up! injector has a cache which is filled with the object returned by the factory method of a Fire Up! module. Hence, those modules are only singleton within the scope of a single Fire Up! injector instance. If you create multiple Fire Up! injectors or require a Fire Up! module manually you will produce multiple instances of your module. A rule of thumb would be to never require a Fire Up! module manually and if you use multiple Fire Up! injectors make sure they cover distinct groups of the available Fire Up! modules.
 
+To make an existing module available to Fire Up! you would usually add the required code according to [the Fire Up! module pattern](#the-fire-up-module-pattern) and move the existing code into the factory method. However, if that is not a viable solution you may register the unaltered code as a [custom module](#passing-custom-modules).
+
 ## API
 
 [![unstable](http://badges.github.io/stability-badges/dist/unstable.svg)](http://github.com/badges/stability-badges)
@@ -802,6 +804,30 @@ The `newInjector(options)` function will throw an error if a configuration error
 
 Additionally, the `use` option and any other custom properties can be passed with options. The options object is later merged with the options passed to a `fireUp(moduleReference, options)` call. This helps reducing duplicated configuration in multiple `fireUp(...)` calls.
 
+#### Passing Custom Modules
+
+In cases where implementing a module in a separate js file which follows the Fire Up! module pattern is not preferable the object that would otherwise be exported can be passed to the `options.modules` array directly. E.g.:
+
+``` js
+var myCustomModuleInstance = ...;              // E.g. a module instance is already available.
+
+var fireUp = fireUpLib.newInjector({
+  basePath: __dirname,
+  modules: [
+    '../lib/**/*.js',                          // Strings still provide paths to module files.
+    '!../lib/templates/**/*.js',
+    {                                          // Objects provide custom modules.
+      implements: 'myCustomModule',
+      factory: function () {
+        return myCustomModuleInstance;
+      }
+    }
+  ]
+});
+```
+
+The passed object can contain the same keys as `module.exports` according to [the Fire Up! module pattern](#the-fire-up-module-pattern). Fire Up! processes custom modules exactly the same way as modules loaded through the given paths.
+
 ### fireUp(moduleReference, [options] ) -> Promise
 
 Overview:
@@ -1074,8 +1100,10 @@ If you want to debug a test you should use `grunt jasmine_node_no_coverage` to r
 
 ## Change History
 
-- v0.4.0 (forthcoming)
+- v0.4.0 (2014-07-20)
+  - Support for [passing custom modules](#passing-custom-modules) to `fireUpLib.newInjector(...)`.
   - `this` within the factory method of a module now points to `module.exports`.
+  - Updated dependencies
   - **Minor Braking Change:** Renamed `FILE_STATUS_...` constants to `MODULE_STATUS_...`.
 - v0.3.2 (2014-07-01)
   - Updated dependencies
@@ -1129,7 +1157,7 @@ If you want to debug a test you should use `grunt jasmine_node_no_coverage` to r
 
 ## License (MIT)
 
-Copyright (c) analog-nico
+Copyright (c) Nicolai Kamenzky (https://github.com/analog-nico)
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of
 this software and associated documentation files (the "Software"), to deal in

concept.md

@@ -6,6 +6,10 @@
 - Implement logging adapter
 - Circular dependency detection for modules of type 'multiple instances' and for singletons in case nested fireUp calls with 'fireUp/currentInjector' are used
 
+## Enhancements
+
+- Extend the module pattern to alternatively take `instance` or `constructor` instead of `factory`.
+
 ## Missing Features
 
 - Destroy support

package.json

@@ -1,6 +1,6 @@
 {
   "name": "fire-up",
-  "version": "0.3.2",
+  "version": "0.4.0",
   "description": "Fire Up! is a dependency injection container designed specifically for node.js with a powerful but sleek API.",
   "main": "lib/index.js",
   "scripts": {
@@ -31,15 +31,15 @@
     "node": ">=0.10.0"
   },
   "dependencies": {
-    "bluebird": "~2.2.1",
+    "bluebird": "~2.2.2",
     "lodash": "~2.4.1",
     "simple-glob": "~0.1.0"
   },
   "devDependencies": {
     "avow": "~2.0.1",
     "deferred": "~0.7.1",
     "deferreds": "~1.1.0",
-    "express": "~4.5.1",
+    "express": "~4.6.1",
     "grunt": "~0.4.5",
     "grunt-cli": "~0.1.13",
     "grunt-contrib-clean": "~0.5.0",
@@ -51,15 +51,15 @@
     "jasmine-reporters": "~1.0.0",
     "kew": "~0.4.0",
     "lie": "~2.7.7",
-    "morgan": "~1.1.1",
+    "morgan": "~1.2.0",
     "mpromise": "~0.5.1",
     "node-promise": "~0.5.10",
-    "p-promise": "~0.3.4",
+    "p-promise": "~0.3.8",
     "promise": "~5.0.0",
     "q": "~1.0.1",
     "rsvp": "~3.0.9",
     "supertest": "~0.13.0",
     "vow": "~0.4.5",
-    "when": "~3.3.1"
+    "when": "~3.4.1"
   }
 }