Silex Replacement
  • Updated on 24 Jan 2020
  • 4 minutes to read
  • Print
  • Share
  • Dark
    Light

Silex Replacement

  • Print
  • Share
  • Dark
    Light

Originally, Silex was used to integrate Symfony Components with Spryker using Service Providers. In addition to that, there are multiple other Service Providers added by Spryker and customer projects to bootstrap the application. Such providers implement Symfony components and other entities by adding them to the Pimple container. Since Silex project is abandoned and the Pimple version is outdated, we are intended to replace them with a Spryker solution.

What do we need to replace?

There are 2 things that are to be replaced: silex/silex, as it is no longer maintained, and pimple/pimple, since the version we are using is outdated.

To be able to eliminate Silex, we need to remove any dependencies on the abandoned silex/silex project that we are using in Spryker (version 1.3.6). The Spryker code will be refactored gradually until it becomes independent of SIlex. On top of that, we added a new Spryker Application to replace the Silex one and a container to substitute Pimple.

What about backward compatibility?

To avoid forcing an immediate update to a majority of Spryker modules, we introduced several small changes. Each of them is backward compatible.

As Silex used to be an instance of Pimple with all services attached to, we introduced our own Container that implements the ContainerInterface from PSR-11. Additionally, we added a mock class for Pimple that further extends the Container. The mock allows us to keep using the \Pimple; use statement without having the pimple/pimple package installed. This way, we eliminate the need to refactor the code that makes use of Pimple. This makes any changes fully backward compatible.

What will change?

Application Plugins

Since ServiceProviderInterface is not provided anymore, any code that implements it needs to be migrated to the new model. Spryker will provide a proper replacement for each Service Provider. To do so, we introduce Application Plugins. An Application Plugin is a plugin that integrates a certain service (e.g. Twig, Form, Security, Routing, etc.) to the application. Each plugin is added to the corresponding ApplicationDependencyProvider.

Service Extension

With Silex, it was possible to extend or overwrite existing services. Now, instead of adding multiple Service Providers, it is possible to use extension points for the services. This means that each service added as an Application Plugin (e.g. Twig) will have its own extension interface.

Existing Service Providers

The already existing Service Providers will remain unchanged, however, from now on, we will be creating Application Plugins to use instead of Service Providers. Such Application Plugins will also have extension points to add or change the functionality when necessary.

What do projects need to do?

General

First of all, customer projects need to update several Spryker modules and other packages. Ideally, there should be no outdated Sprkyer module in use. However, the main ones are spryker/silex, spryker/application, and spryker/container. The minimum versions that allow migrating away from Silex and Pimple are as follows:

  • spryker/application >= 3.13.2
  • spryker/container >= 1.1.0
  • spryker/silex >= 2.1.0
  • spryker/symfony >= 3.2.2
  • spryker-shop/shop-application >= 1.4.1

The versions above are the minimum requirements to allow migrating away from Silex. Projects are strongly advised to upgrade to the latest version of each module available.

In some older Spryker Commerce OS or Spryker Demoshop versions, there were dependencies added directly to the composer.json of the projects. Projects based on those versions need to make sure that the mentioned modules do not appear as project dependencies and that there are no constraint points to silex/silex, spryker/pimple, or pimple/pimple.

Under certain circumstances, an update does not contain the latest versions of the required Spryker modules. To find out why they are not installed, you can use the why and why-not commands provided by Composer. They will help you to update the dependencies.

Specific Services

The modules listed below have been refactored to use Application Plugins. Projects need to perform additional steps to migrate the modules to the latest version.

Modules that need to be migrated away from Silex:

How to extend or change the services?

Previously, if we wanted to extend a service (for instance, Twig) with new functions or global variables, we would need to add a new Service Provider and use the extend functionality provided by Pimple to manipulate a registered Service Provider. After that, it would be necessary to add the Service Provider to Silex Application. This option remains available, however, it is preferable to use the provided extension interfaces for each of the services used.

Let us review the example of Twig. The Twig module contains TwigApplicationPlugin. On top of that, there is the TwigExtension module that brings at least one interface that can be used to extend Twig. Instead of adding multiple Service Providers to the application, we only need to add the TwigApplicationPlugin to the ApplicationDependencyProvider. If we need to further extend Twig, we simply add a plugin to TwigDependencyProvider.

Was this article helpful?