I can see the caching argument, but what is it that we actually need and which we don’t know anyway in the class loader for example? I’d be happy to get some examples.
For things not being installed via composer, that’s actually the norm I’d say. The original usecase for composer is to pull in 3rd party libs to be used together with your application, and that is more often than not just a bunch of code, and not a composer package on it’s own. So it seems 99% of the people just pull in those libraries, require the autoload.php composer generates and are done with it. What else do we need on top of that?
Folders of existing packages to register them (used to resolve all kinds of paths inside like configuration, resources etc.)
currently autoload information (could be dropped when we do not have disabeld packages anymore)
Precalculated information about eventual Package.php files that we need to load for booting
Flow package key => composer package name mapping
So with disabled package gone we could get rid of 2 probably. 3 is just soo much faster when precalculated same goes for 4 which we could get rid off when we would use only composer package names directly. We would still need to keep track of all package folders available to register them for configuration and resource management (and get class files for proxy building, and and and).
I still would like to, maybe change it to something like a cache for package names and folders. (pretty much what it is now). I doubt we can get fully rid of it, my post from July is still accurate on that.
Yeah, if it is in fact a cache, it should work like one. There’s currently too much special handling around the PackageStates that makes it fragile and when things don’t work, you have to manually delete it.