Module preferences

Mosaic introduces concept of module preference. This is a feature of extensions.

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.

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

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.

Virtual module preference

Mosaic introduces the concept of "virtual module".

Virtual module - a non-existing module, referenced in the code. It provides an abstraction layer, which allows to swap the implementation.

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 in your extension to it. To ensure that it does not exist, use @virtual-module/<name> name for it.

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.