# \[RFC\] laminas-cache satellite packages

**URL:** <https://discourse.laminas.dev/t/rfc-laminas-cache-satellite-packages/1543>\
**Category:** Contributors\
**Tags:** laminas-cache\
**Created:** [April 20, 2020, 3:10pm UTC](https://discourse.laminas.dev/t/rfc-laminas-cache-satellite-packages/1543 "2020-04-20T15:10:12Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![boesing](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.laminas.dev/boesing/32/832_2.png) [@boesing](https://discourse.laminas.dev/u/boesing)\
**Post date:** [April 20, 2020, 3:10pm UTC](https://discourse.laminas.dev/t/rfc-laminas-cache-satellite-packages/1543/1 "2020-04-20T15:10:12Z")

</div>

## Goal

As there are plenty of storage backends provided with laminas-cache, I would like to introduce satellite packages for each of them.  
The same goes for plugins.

## Background

Any cache backend has its own unit/integration tests. To test the compatibility, we have to enable/disable the tests so we do not have to wait ages for results if we changed a plugin for example. Furthermore, the compatbility of the storage backend is being checked during instantiation:

```php
if (! extension_loaded('redis')) {
    throw new Exception\ExtensionNotLoadedException("Redis extension is not loaded");
}

```

The same goes for the `Serializer` plugin where the `laminas-cache` `composer.json` suggest installing `laminas-serializer` to work properly.  
The `PluginOptions` contains options for all plugins. I would prefer having the same logic as with the `StorageOptions` and let satellites extend the options if necessary.

satellite packages are the best way to solve all those issues:

1. we can execute tests for the specific satellite package without enabling the unit tests within phpunit file
2. we can set explicit package requirements with composer (starting with v3)
3. we can archive/deprecate packages more easier if needed (for example, APC would be one of those we can archive as its abandoned since 2012)

## Considerations

- Having multiple satellites might raise the need for more maintainers.
- Maintainability for 20+ new libraries might be awful.
- Creating template repositories for plugins and storages.
- Creating `laminas/laminas-cache-storage-implementation` virtual package (can be packed with the `composer.json` of the template repository)

## Suggested Approaches

### satellites to create

I’ve thought about creating satellite packages for all storage adapter aswell as all plugins.  
For the current version `laminas-cache` 2.9.0, we would end-up with the following satellites:

#### Storages

- Apc
- Apcu
- BlackHole
- Dba
- ExtMongoDb
- Filesystem
- Memcache
- Memcached
- Memory
- MongoDb
- Redis
- Session
- WinCache
- XCache
- ZendServerDisk
- ZendServerShm

#### Plugins

- ClearExpiredByFactor
- ExceptionHandler
- IgnoreUserAbort
- OptimizeByFactor
- Serializer

We could create template repositories for both storage- and plugin-satellites.

This would provide contributors an easy way to easily create either a storage backend for their own (as I did already with [boesing/zend-cache-redis-cluster](https://github.com/boesing/zend-cache-redis-cluster)) and/or provide it to the laminas organization. Either way, having templated storage backends and/or plugins makes it easier for others to contribute to the laminas ecosystem even without sharing the code with the laminas organization at all.

### Virtual package for storage backends

With v3, we could go with `laminas/laminas-cache-storage-implementation` as a virtual package (like `psr/container-implementation`) and thus, the migration process will force the user to choose at least one storage implementation as the `laminas/laminas-cache` repository does not contain any storage anymore.  
der

## Alternatives

- Creating only satellites for those plugins/storages which require external dependencies and thus need “suggest” entry in the `composer.json`
- Stay with a cache monorepo

## Unresolved questions

- Should we create satellites for all plugins or just for those with dependencies?
- Do we need maintainers for each satellite?
- Can we already drop more storages than just `Apc`?
- Should we create satellites and attach them to the current `laminas-cache` `composer.json` and drop them with v3?
- Namings for satellites?
  - Storages?
    - `laminas/laminas-cache-storage-*` e.g. `laminas/laminas-cache-storage-redis`
    - `laminas/laminas-cache-*` e.g. `laminas/laminas-cache-redis`
    - `laminas/laminas-cache-*-storage` e.g. `laminas/laminas-cache-redis-storage`
    - other? Feel free to comment!

  - Plugins?
    - `laminas/laminas-cache-plugin-*` e.g. `laminas/laminas-cache-plugin-serializer`
    - `laminas/laminas-cache-*` e.g. `laminas/laminas-cache-serializer`
    - `laminas/laminas-cache-*-plugin` e.g. `laminas/laminas-cache-serializer-plugin`
    - other? Feel free to comment!

- Should we go with `laminas/laminas-cache-storage-implementation` with v3?