Implement "autoload warmers" so tab completion and PsySH commands work with all classes.
Opened this issue · 9 comments
i imagine it would be an interface, and maybe a couple of implementations. one based on composer, that reads either configs or generated autoloaders, uses them to enumerate all possible classes. another could be symfony finder based, and walk the filesystem according to the finder rules.
in all cases, we probably just want them to emit a list of files which possibly / probably contain classes, then use php parser to parse the file and make sure (1) it's valid PHP and won't error, (2) it contains only class and function definitions at the top level, not things that probably have side effects.
Originally posted by @bobthecow in #539 (comment)
👆See that issue for more discussion.
What about just using composer's optimised autoloading mechanism. That already produces class mappings for us.
Moreover, it means we don't need to care about the (auto)loading mech ism for classes. They need not be PSR-0/4, even (which means requiring the files could have side effects other than defining a class/interface/trait).
Because nobody uses the optimized autoloader in development?
This warning seems like a pretty good reason not to 😀
But if it's possible to dump the autoloader somewhere else, or just dump to memory once, on launching the shell, or something like that, it might work?
I mean, I use psysh in production all the time. ;)
Composer's ClassMapGenerator itself could be a good autoload warmer:
That runs on PsySH's source in ~0.02s, which is fast enough to do once on every shell session and just store it in memory.
Adding a dependency on composer/composer just to get the ClassMapGenerator doubles the size of PsySH's vendor directory :-/
The problem with doing that is we could require files that are not meant to be required. That is just doing the "classmap" strategy, right?
The best strategy, I think, is just do an optimised autoload dump, possibly to some temp location, to give us an accurate list of all the classes, defined by the autoloading strategies from people's composer.json files, and that of the dependencies?
playing with a hacked up version of this, i'm not convinced we want to pre-warm vendor. there's a lot of transitive dependencies in there that i don't want cluttering up my tab completion :P
so maybe we make it opt-in? prefix based? namespace based? there's a sweet spot somewhere in here, but i'm not sure it's "every class known to composer".