<commit_before>![Scatter logo](https://raw2.github.com/mariocasciaro/resources/master/scatter_text_lg.png)

[![NPM version](https://badge.fury.io/js/scatter.png)](http://badge.fury.io/js/scatter)
[![Build Status](https://travis-ci.org/mariocasciaro/scatter.png)](https://travis-ci.org/mariocasciaro/scatter)
[![Coverage Status](https://coveralls.io/repos/mariocasciaro/scatter/badge.png)](https://coveralls.io/r/mariocasciaro/scatter)
[![Dependency Status](https://gemnasium.com/mariocasciaro/scatter.png)](https://gemnasium.com/mariocasciaro/scatter)
[![Gitter chat](https://badges.gitter.im/mariocasciaro/scatter.png)](https://gitter.im/mariocasciaro/scatter)

Scatter is an **Inversion of Control (IoC) container** for Node.js. Scatter allows you to split your project in **particles** (components), and then uses **Dependency Injection** and **Service locator** to link your modules together.

Applications created with Scatter are **extensible out-of-the box**. Since every dependency is "virtual", you can override and extend every module. In addition by using Scatter [Services](#services) you can provide explicit extension points to your application.

Every module created for Scatter is totally agnostic to the IoC container and **can be used even without it**. Scatter modules are POJOs (Plain Old Javascript Objects), simply objects, factories and constructors that accept their dependencies as input. The only difference from a *plain* module is that Scatter reads an annotation named `__module` to extract the information to initialize the module and inject dependencies.

-----

### [Full Guide](https://github.com/mariocasciaro/scatter/wiki/Guide) | [API docs](https://github.com/mariocasciaro/scatter/wiki/API-Documentation)

-----

## Scatter virtual directory federation

Although Scatter can be used as a "traditional" IoC container and has many usage patterns, the main reason for his existence is to allow the federation of multiple project directories into one. Dependency Injection, in fact, is not the reason Scatter was created but only a tool which allows to **transparently map multiple components**, called **particles** (which may also be distributed as npm pagackes), into **one virtual namespace**. It doesn't matter where a module is created, when used with Scatter it will always have a federated view over all the other modules in the project. 

![Scatter federation](https://raw.githubusercontent.com/mariocasciaro/resources/master/scatter_federation.png)

Where is the advantage of this you may ask...well imagine those components as plugins, you app would become immediately extensible with minimal effort and no boilerplate code to support the plugin infrastructure.

The use cases? Here are some:
* Create a CRM (or any other business app) and need to customize it for some clients whitout branching the code
* Create a blog/forum/CMS and want people to extend it using plugins
* Add all the use cases where an IoC container can improve decoupling and testing.


## Features

* Split your project into **components (particles)** and wire  modules using **Dependency Injection**.
* Define your modules as you want: factories, constructors or plain objects. 
* Your modules do not need to know who is instantiating them or wiring them, they are totally **decoupled from Scatter and will work even without it**.
* Instantiate and initialize modules **asynchronously** (just return a promise).
* **Services framework** built on top of the IoC container (with sync and async execution)

## Examples

If you prefer to go straight to the code then take a look at some [examples](https://github.com/mariocasciaro/scatter/tree/master/examples).<commit_msg>Fix Services link and add download badge<commit_after>![Scatter logo](https://raw2.github.com/mariocasciaro/resources/master/scatter_text_lg.png)

[![NPM version](https://badge.fury.io/js/scatter.png)](http://badge.fury.io/js/scatter)
[![Build Status](https://travis-ci.org/mariocasciaro/scatter.png)](https://travis-ci.org/mariocasciaro/scatter)
[![Coverage Status](https://coveralls.io/repos/mariocasciaro/scatter/badge.png)](https://coveralls.io/r/mariocasciaro/scatter)
[![Dependency Status](https://gemnasium.com/mariocasciaro/scatter.png)](https://gemnasium.com/mariocasciaro/scatter)
![Downloads](http://img.shields.io/npm/dm/scatter.svg)
[![Gitter chat](https://badges.gitter.im/mariocasciaro/scatter.png)](https://gitter.im/mariocasciaro/scatter)

Scatter is an **Inversion of Control (IoC) container** for Node.js. Scatter allows you to split your project in **particles** (components), and then uses **Dependency Injection** and **Service locator** to link your modules together.

Applications created with Scatter are **extensible out-of-the box**. Since every dependency is "virtual", you can override and extend every module. In addition by using Scatter [Services](https://github.com/mariocasciaro/scatter/wiki/Guide#services) you can provide explicit extension points to your application.

Every module created for Scatter is totally agnostic to the IoC container and **can be used even without it**. Scatter modules are POJOs (Plain Old Javascript Objects), simply objects, factories and constructors that accept their dependencies as input. The only difference from a *plain* module is that Scatter reads an annotation named `__module` to extract the information to initialize the module and inject dependencies.

-----

### [Full Guide](https://github.com/mariocasciaro/scatter/wiki/Guide) | [API docs](https://github.com/mariocasciaro/scatter/wiki/API-Documentation) | [Plugins](https://github.com/mariocasciaro/scatter/wiki/Plugins)

-----

## Scatter virtual directory federation

Although Scatter can be used as a "traditional" IoC container and has many usage patterns, the main reason for his existence is to allow the federation of multiple project directories into one. Dependency Injection, in fact, is not the reason Scatter was created but only a tool which allows to **transparently map multiple components**, called **particles** (which may also be distributed as npm pagackes), into **one virtual namespace**. It doesn't matter where a module is created, when used with Scatter it will always have a federated view over all the other modules in the project. 

![Scatter federation](https://raw.githubusercontent.com/mariocasciaro/resources/master/scatter_federation.png)

Where is the advantage of this you may ask...well imagine those components as plugins, you app would become immediately extensible with minimal effort and no boilerplate code to support the plugin infrastructure.

The use cases? Here are some:
* Create a CRM (or any other business app) and need to customize it for some clients whitout branching the code
* Create a blog/forum/CMS and want people to extend it using plugins
* Add all the use cases where an IoC container can improve decoupling and testing.


## Features

* Split your project into **components (particles)** and wire  modules using **Dependency Injection**.
* Define your modules as you want: factories, constructors or plain objects. 
* Your modules do not need to know who is instantiating them or wiring them, they are totally **decoupled from Scatter and will work even without it**.
* Instantiate and initialize modules **asynchronously** (just return a promise).
* **Services framework** built on top of the IoC container (with sync and async execution)

## Examples

If you prefer to go straight to the code then take a look at some [examples](https://github.com/mariocasciaro/scatter/tree/master/examples).
{'fraction_non_alphanumeric': 0.0957222075521521, 'fraction_numerical': 0.0002640612622128334, 'mean_word_length': 5.188725490196078, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 30, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1807990', 'n_tokens_mistral': 2093, 'n_tokens_neox': 2039, 'n_words': 851}