# Module preferences

Mosaic introduces concept of module preference. **This is a feature of** [**extensions**](https://docs.mosaic.js.org/experimental/broken-reference).

{% hint style="info" %}
**To preference a module** means to take-over another NPM or virtual module. To take-over means to completely replace an implementation, the original module will not be available.
{% endhint %}

To preference a module, set the `mosaic.preference` field of `package.json` equal to the desired module name.

{% hint style="danger" %}

## Watch out!

This is very dangerous to preference a real NPM module, like in example `react` or `redux`. While it is possible do that, this feature is meant only for [virtual module preference](https://docs.mosaic.js.org/experimental/broken-reference).
{% endhint %}

## Virtual module preference

Mosaic introduces the concept of "virtual module".

{% hint style="info" %}
**Virtual module** - a non-existing module, referenced in the code. It provides an abstraction layer, which allows to swap the implementation.
{% endhint %}

Virtual modules are useful for UI elements, where different libraries could be used as an implementation, or for an API endpoints, where the application is relying on data format, not the source of the data.

To create a virtual module, define the reference to a non existing module, and [implement a preference](https://docs.mosaic.js.org/experimental/broken-reference) in your extension to it. To ensure that it does not exist, use `@virtual-module/<name>` name for it.

{% hint style="danger" %}

## Watch out!

This is a subject to change. We plan on providing a more robust way to depend on virtual modules. **They should be coupled with typescript interfaces**. Currently, virtual-modules only work on the level of module resolution, they do not provide any interface for the implementation.
{% endhint %}