Developers tool for WordPress plugins: Wraps all your projects dependencies in your own namespace, in order to prevent conflicts with other plugins loading the same dependencies in different versions.
As @szepeviktor mentioned, the PHAR we created starting from the last release was way too big (at a whopping 14MB). This was caused because all the development dependencies were included as well. This release changes that, reducing the created PHAR to 1.3MB.
This release quickly follows the 0.6.0 release and is focussed on solving the problems with distribution and isolation Mozart has been facing. That's why Mozart is now available as a Docker image and a PHAR file will be attached to each release and can be downloaded from the releases page (or via Phive). All of this is to ensure that Mozart can run in isolation itself and not have potential conflicts with your projects dependencies (yes, for a package claiming to solve dependency conflicts, this is crazy meta - I know!).
I've also put lots of attention to the installation instructions in the README, explaining how the different installations methods work and point at the pros and cons for each.
Mozart is now supporting all supported PHP versions, which include: PHP 7.3, 7.4 and 8.0. Support for PHP 7.2 has been dropped.
Other than the logistical part of the project, 0.7.0 is a very small release. No actual code has been changed, apart from some code standards and minor fixes. The availability of the Docker image and the building of PHAR files is a big step forward though!
This has been in the works for far longer than it should have. Special thanks to @BrianHenryIE as he has been so hard at work with multiple changes and debugging things for other developers, in the issues. I try to scrape every single bit of time that I can put into Mozart, but I don't know how I could do it without him. 🎉
In this release, the highlights are:
packages
key in the configuration and Mozart will transform all packages.override_autoload
configuration key, you can specify the autoload configuration for that package, after it is transformed by Mozart.excluded_packages
configuration key you can disable a package from being transformed by Mozart. This is useful for packages, for example PSR-11's ContainerInterface
that is a standardised class.Besides the highlights, Mozart has been improved across the board. A whole lot of fixes have been merged over the past couple months, that have made the code base more solid and bug free.
Aside: By the end of last year, I posted a long post about my thoughts about the future of Mozart: The future of Mozart - we're at a crossroad! - I've spent the first weeks of this year, thinking this through some more. Right now, I feel I have a solid understanding of the most pressing issues within our tiny ecosystem. Enough at least, to put a little roadmap together, which I'll post soon. The next release of Mozart will be all about distribution of the package, adding a Docker image and possibly other means of running the code, in addition to requiring Mozart as a package in your project. More on that soon!
composer.json
file is valid #49.gitkeep
file in order to persist the directory in CVS #52Thank you @markjaquith and @BrianHenryIE for your contributions! 🎉
Second beta today, but I have messed up something while reviewing and that is now fixed.
With so much going on, I feel a proper beta for this next release is in order. I'd like to run this through some rigorous testing before tagging the stable release.
I still want to check if #42 is still required after #39 is already merged.
Thanks a ton, @BrianHenryIE for all the help and contributions. I'll get your contributions properly attributed in the release notes once this becomes the next stable.
Fixed: Symfony command must have an integer as return status code (#33)
Santa came early and dropped a new release of Mozart. This release contains:
/vendor
directory. This has been on my radar for a while to test out, but this bug proved that it was worth my while.Version 0.4.0 of Mozart is here. The main change that everyone will notice is that Mozart now requires PHP 7.1 and up. The reasoning behind this is documented in #26, but the tldr is:
Mozart is a developers tool. In my humble opinion, developers should lead by example in using supported PHP versions only and have no reason to stay behind on unsupported versions.
Further changes in this release:
^4
now of both symfony/console
and symfony/finder
packages). See #25 for more details.Big thank you to everyone contributing to and using Mozart, your help is very much appreciated! 🎉
Thanks to the hard work of @costasovo in his attempt to support rewriting the full dependency tree in #10, I have been able to tackle this issue now finally. This release contains: