[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:  4.7
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by MikeSchinkel):

 Replying to [comment:173 TJNowell]:
 > That makes no sense, that's not how Composer works, perhaps you've
 misunderstood use of composer for inclusion of composers entire codebase,
 something that is not being suggested. The language could be misleading
 for somebody without knowledge of how Composer is used.

 What makes no sense?  My comments on @schlessera's comment, or
 @schlessera's comment?

 If you think the former, please explain how my language is misleading.

 If the latter, then of course I agree, but don't shoot the messenger.

 > These are the PSR standards, we don't use those, and we don't need to,
 this ticket discusses classmaps, and the classmap autoloader is what's
 under discussion. You do not need to put classes in the vendor folder to
 autoload them, and you do not need to follow PSR conventions.

 Exactly. So if we do not need PSR standards then why use a tool that was
 purpose-built to support PSR standards and bring along all its related
 baggage?

 > This is the core autoloader, mu-plugins and plugins are not core, plugin
 developers can and do handle loading of files themselves, this is a
 separate topic.

 Why paint ourselves into a corner like that? It is downright foolish to
 adopt a solution for just core and ignore how it would eventually be used
 for plugins and themes especially since we've already pointed out how
 problematic using it would be for plugins and themes.

 To illustrate the mismatch with Composer and WordPress with Plugins and
 Themes let me quote from the Composer team member's comment
 [https://github.com/composer/composer/issues/3852#issuecomment-172937526
 that I linked] but you evidently missed:

  Pretty much every project except wordpress at this point works in the
 same way: you have a composer.json and declare the list of plugins you
 want, and they get installed, and that's that. One autoloader, then some
 plugins/libraries/whatever packages. If every wordpress plugin embeds a
 composer autoloader, it's because the ecosystem is broken and wordpress
 core doesn't give a damn about moving forward. It's not something I am
 willing to waste time on I'm sorry..

 > Some plugin authors may wish to use PSR0/4, and it would prevent
 compatibility problems if a plugin required a library that used such
 standards.

 What compatibility problems?  The plugin cannot use PSR0/4 '''AND''' the
 pre-generated autoloader that is being proposed for inclusion in core
 ''unless the plugin moves its files into the `/vendor` directory (or
 similar)'', which is a non-starter.

 '''Composer autoloader generation is designed to be used at project
 ''(site)'' build time. That simply does not match how WordPress plugins
 and themes work.'''

 If a site builder wants to use PSR4 to autoload their own plugins classes
 then they can use Composer and there will be no compatibility problems.

 > For example
 [https://github.com/rmccue/Requests/blob/master/composer.json
 rmccue/requests]

 And Requests is a '''PHP library''', it is not a WordPress plugin or
 theme. And it would be included at '''build time'''.  So whoever wants to
 use it and Composer can with no compatibility problems with a simple core
 autoloader.

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