as you might know or not you can disable installed packages in a Flow/Neos application.
See ./flow package:deactivate
This is nice but hails from times before composer was a thing. Together with composer it’s pretty hard to maintain such a state on top and it’s not perfectly reliable. For most parts it works quite ok but it has problems for UnitTests for example. Also it adds a lot of complexity to Flow. So all in all I would be in favor of removing the feature altogether.
I would like to discuss this a bit before actually starting a poll for a final decision. So give me your input please
Composer doesn’t have a disabled flag AFAIK and probably for a reason.
Personally I’d be in favor of getting rid of the PackageStates.php file altogether in the mid term. It just duplicates information we already have in the composer manifest(s) and it does so by skipping some of the important details (e.g. it only respects the first autoload instruction).
Instead of removing this feature without replacement we could move disabled packages to a folder “_DisabledPackages” or similar… At least this is what I currently do if I want to disable a (non-versioned) package temporarily
Yeah, we can disucss that, but then again we need to track that and the dependency chain might be broken afterwards without us knowing.
I see the PackageStates transforming more and more into a cached merge of all composer.jsons. Problem is that we need quite some information from them during runtime and you don’t want to read all of them. Also with the current “best practice” of base respository + site package (or any other package) - which I still find no good idea - we need PackageStates to keep track of those packages that are actually there but not composer installed. (Think Bootstrap, Resources etc.)
We may or may not need PackageStates.php to hold information (be it as a cache for composer manifests or packages not even installed via composer), but I agree that the “disabled packages” thing should be removed. I never used it, would never rely on it for production purposes anyway (why would I deploy code I am not going to use in the first place) and every code removed is less code to maintain or have bugs.
So for removing “disabled packages” ad making that a task the developer has to solve on his own.