[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

[WordPress Trac]

#36335: Next generation: core autoloader proposal
-----------------------------+-----------------------------
 Reporter:  dnaber-de        |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |     Focuses:
-----------------------------+-----------------------------

Comment (by CoenJacobs):

 Replying to [comment:45 boonebgorges]:
 > A Composer-generated classmap seems like the right way forward here. I
 don't see why we should reinvent the wheel, even if it only takes 47 lines
 to do it.

 I couldn't agree more.

 > I have some implementation questions about how a Composer classmap would
 work alongside the WP codebase, which could probably be answered with a
 patch from someone with more Composer-fu than I've got. Putting a
 composer.json in the root of the repo checkout and running `composer dump-
 autoload` puts the autoloader into `/vendor`. What's the best practice for
 moving it into `ABSPATH`? Should we have a (Grunt?) wrapper that runs
 `dump-autoload` and then moves `vendor` into `src`, intended to be run
 pre-commit?

 Let's answer the question on '''why''' to move it to `ABSPATH` in the
 first place. The Composer autoloader works fine from outside the root of
 your files, it is actually designed to work in that way. Just loading
 `vendor/autoload.php` from really early on, say in `wp-load.php` would
 work fine. The only obstacle in the way of implementing a Composer
 autoloader would be mapping class names to WordPress standard file names,
 which is something Composer offers a way to do so by introducing a custom
 mapper.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36335#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform