[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:                   |     Focuses:
-----------------------------+-----------------------------

Comment (by jtsternberg):

 Replying to [comment:39 schlessera]:
 > Yes, totally agree. But adding Composer autoloading is adding 1 tiny
 file (`composer.json`) and adding 1 line of PHP to one of the
 bootstrapping files (like `wp-load.php`): `require_once( ABSPATH .
 '/vendor/autoload_52.php' );`. This results in a working autoloader that
 keeps everything up-to-date as Core classes are changed.

 This makes total sense to me. Running composer update as part of the grunt
 build process would ensure the class map was always up-to-date, even when
 we begin trying to fix the class/file-naming conventions. The composer
 class-map generator would have us covered. Sounds like the alternative is
 a class-map that has to be maintained by hand? Not sure I understand what
 the benefit there is? Unless it's about cognitive overhead?

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