Last week we released Disco version 0.9.0 with a few new features and unfortunatly some BC breaks. The BC breaks are all covered in the upgrade guide, but I would like to discuss them in greater detail to give you a better understanding why those changes happened:
Since the first release of our ng2-combobox components for Angular the repository is still lacking a decent documentation on how to use the component if you are not that familiar with Angular. This blog post should give you some insights on how to set up the combobox component in an Angular application. If you haven't yet set up an Angular application yourself it is as simple as typing the following command:
Last year GitLab introduced the Review Apps feature. Review Apps are app environments that are created dynamically every time you push a new branch up to GitLab. As a bonus point the app environments are automatically deleted when the branch is deleted. Since we moved to using docker for quite a few of our projects I was keen on figuring out how to combine Docker and the GitLab Review Apps functionality as the documentation only mentions NGINX as a way to run Review Apps. As it turns out, it is rather simple to deploy docker containers as a Review App.
In a recent attempt to upgrade Disco to the latest version of ProxyManager I ran into this FATAL ERROR: "Declaration of Mock_ClassGenerator_f7ebad25::setExtendedClass($extendedClass): ProxyManager\Generator\ClassGenerator must be compatible with ProxyManager\Generator\ClassGenerator::setExtendedClass($extendedClass): Zend\Code\Generator\ClassGenerator" when I tried to execute the unit tests. It took me a while to understand the source of the problem, thus I think sharing the problem might help my future me and probably you as well. Let's assume you have two classes The_Parent and The_Child:
This blog post has been sitting on my desk for quite a while but due to a lot of work in the last weeks I was not able to finish it earlier. Luckily, I found some time during my travels to finish the blog post and share my findings on the "require-dev gone wrong!" problem. While some people thought the former blog post was mostly click bait or proposed a "fix" which does not actually solve the general problem, I actually got a lot of good feedback on twitter. Even an issue for Composer was created to discuss the problem even though it was closed by now.
While working with Zend Expressive, a PSR-7 middleware microframework, I wanted to apply some unit testing with a nice coverage to my middlewares. Middlewares are called by the __invoke method if you provide them as an object and not as a closure. The signature of the __invoke method looks like this:
Yesterday, we released the stable version 2.0 of our Force Login Module for Magento 2. To upgrade, you can get the latest release here, or update the dependency in your composer.json.
For a long time, I have been advocating to make use of require-dev to install development tools locally. We use this on a daily basis to install tools like Phing, PHPUnit or phpDocumentor locally for each of our (customer) projects. Given that our focus is on custom projects, this absolutely makes sense. I do not want our projects to use an old version of a given tool or update all our projects constantly to use the latest version of all the tools involved. In addition to that, a simple composer.phar install in the project root should be sufficient to install all dependencies required to build and run the project.
Using the JMS serializer in recent project, I ran into the problem that the serializer does not support inheritance in a handler configuration. A handler is used to to change the serialization, or deserialization process for a single type/format combination.
In our "old" Jenkins set-up things were simple: The Jenkins master and Satis were running on the same host thus Jenkins could easily invoke Satis via a command-line call. Unfortunately GitLab does not allow that. The only option which is currently available in GitLab is to trigger Satis via a webhook. Neither Satis itself or Satisfy which we actually use provide support for webhooks. Thus we extended Satisfy with a simple controller which invokes the Satis cli command. Definitely not the best solution but it works for us.