When Sylius moved to version 2.0, a significant problem emerged with updating plugins and packages created by developers, often during their spare time outside of work hours.
The challenge quickly became clear: semantic versioning requires frequent updates, plugins must remain compatible with their corresponding Sylius versions, and updating plugins takes considerable time that no one will pay for. While Sylius provides a plugin skeleton that shows developers how extensions should be built, it also includes something called a dependency to a directory with a whole Test Application, and this is where things get complicated.
However, let’s start from the beginning...
What was the problem?
The Plugin Skeleton comes out of the box with a Test/Application. This can be compared to having a plugin for a video game that comes bundled with a specific version of that game.
For example, the SyliusCMSPlugin has the Plugin Skeleton as its foundation. The Plugin Skeleton, in turn, has an out-of-the-box Test Application. In one directory, it has Sylius installed in a specific version. So every plugin version for 1.x has Sylius version 1.x there. This creates a dependency where everything needed to run that plugin is installed locally.
This means the plugin contains both the code for controlling the plugin's logic and the entire Plugin Skeleton that allows testing how that code works with a given version of Sylius. When developing a plugin, you want to continuously check how it works with Sylius, which makes perfect sense.
Until now, every plugin has had its own test app included in the skeleton repository, each with duplicated configs and setups. When minor versions were being used, this wasn't a huge problem. But issues started appearing when it became clear that updating a plugin required dedicating a large portion of work to managing the skeleton rather than the actual plugin logic.
Here's the scale of the problem: a plugin might have 100 files containing the plugin's logic – for example, a CMS plugin includes logic for building blogs or adding images. Meanwhile, the Plugin Skeleton might have 1,000 files. When updating a plugin package, developers had to go through all those 1,000 files, even though they only changed a few files in the actual plugin source code.
This can be compared to creating skins for a video game, where each skin requires downloading a specific version of that game. As a result, two hours are spent creating a skin, and then fifteen hours are spent going through the file by file to replace the video game version.
Plugin developers therefore had to update not only their own code but also the entire test application to maintain compatibility with newer Sylius versions. Even at BitBag, we initially assumed this was a natural cost. In practice, this proved to be a frustrating and time-consuming process – every simple update meant having to change the Sylius version in the framework. And with around 500 plugins in the ecosystem, this meant hundreds of people reviewing thousands of files with each update.
This is frustrating work because a simple update means having to update the Sylius version in the Plugin Skeleton. When you have around 500 plugins in the ecosystem, 500 people have to go through those 1,000 files each time there's an update.
The new test application solution
To simplify the plugin update process for the community and help them transition to Sylius 2.x, significant changes were made to this process. Sylius has just released something that's been missing in their standard for years - a shared, official test app for plugin development. They decided to move the TestApplication so it can be installed into any plugin source in a way that places it in the vendor directory – a replaceable location that developers don't directly access.
This means Sylius manages the TestApplication and updates it centrally, while plugin creators can focus on controlling their application logic. The result is a significantly "slimmed down" Plugin Skeleton where Sylius leaves space for editing only the part what controls the plugin's logic, not the entire infrastructure needed to run the plugin package.
The new app accelerates development by reducing manual integration steps – in many cases, developers won't need to touch configuration or Webpack settings at all. Thanks to Symfony Flex and custom recipes, installing a plugin can now be as simple as running one install command.
This represents a substantial change for two key reasons. First, the plugin upgrade process has been significantly shortened, eliminating much of the tedious file management work. Second, Sylius can now centrally switch framework versions in one place and easily test how different plugins behave across 1.4, 2.0, 2.1, as well as any future or past releases.
.png)
Thanks to this approach, Sylius has simplified migration and accelerated the plugin update process, allowing creators to focus on the plugin itself (what they actually wrote) rather than the entire infrastructure. Plugins have been reduced by hundreds of files, and creators have far fewer files to maintain. Every time a new version comes out, manual updates are no longer required.
This can be thought of as a Sylius "emulator" that allows developers to check how the plugin behaves with Sylius. Now, there is one clean, reusable app, officially maintained by the Sylius team, compatible with 2.0+, and ready to make plugin work smoother and faster.
Real-world implementation
Sylius has already used the new TestApplication internally for the recently announced CMS Plugin, and it works like a charm. This real-world testing demonstrates that the solution isn't just theoretical but has been proven in actual development scenarios.
The success with the CMS Plugin has been so positive that Sylius will most likely migrate all of their extensions to use this as a standard shortly. This commitment from the core team shows confidence in the solution and sets a clear direction for the entire ecosystem.
What does this mean for developers
For plugin developers, this change represents a fundamental shift in how they approach their work. The development (or upgrade) process becomes way easier and far more enjoyable for the whole Sylius community, reducing plugin packages by an average of several hundred files. Instead of wrestling with infrastructure concerns, developers can focus entirely on the unique value their plugins provide.
The standardization also means better consistency across the ecosystem. When all plugins use the same testing foundation, it becomes easier to maintain quality standards and ensure compatibility across different extensions.
{{cta-technology-sylius="/comp/cta"}}
Wrapping up
This change saves developers hundreds of hours by simplifying the entire plugin update process. The community can now focus on what matters most – building innovative eCommerce plugins, rather than spending time on infrastructure updates.
Furthermore, the community is encouraged to try out the new TestApplication (documentation), share feedback, and contribute to further improvements. This collaborative approach ensures that the solution continues to evolve based on real developer needs and experiences.
<div class="rtb-text-box is-blue-50">Are you looking for Sylius specialist? Contact us and arrange a free consultation.</div>
