[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:226 Rarst]:
 > The degree of this misquote of me is so horrible I can't even. I spent
 literally years advocating for Composer use with WordPress.

 It was not my intent to misquote you.  I am well aware of your composer
 advocacy and your website devoted to such but I also believed based on
 your writings that you did not advocate Composer as a tool for every job.

 There are multiple contexts in which Composer can be used and as I read
 your comments I came away thinking you advocated for Composer in some
 contexts but recognized and acknowledged it not to be a fit in others.
 Specifically that Composer was great for managing the code base for
 WordPress websites but not appropriate for managing the dynamic
 installation of plugins and themes.

 Please tell me if I got that wrong, and if so then consider my quoting
 retracted and please accept my apology.

 ----

 BTW, before anyone points out that the proposal on the table is to
 ''only'' to use Composer to build WordPress and to include a Composer-
 generated classmap and Composer-generated autoloader into core I
 understand that but have also seen that at least some of the advocates for
 this approach have indicated that they saw this as a first step to having
 Composer fully integrated into and shipping with WordPress. Hence some of
 my strong objection on this ticket.

 To be explicit, let me bullet point my arguments for where to use Composer
 and where not to use Composer:

 1. '''To build WordPress core''' - Wonderful, '''no problem''' with this
 at all.  Knock yourself out.

 2. '''To generate a classmap for core''' - This '''might or might not be a
 good idea''', but it seems trivial to implement
 ''([https://github.com/mikeschinkel/develop.wordpress/blob/00f1700b5abac3c7ad0a91282605b15ea464f6c9/tools/classmap
 /class-classmap-generator.php as you can see here])'' and I question the
 wisdom of including a tool in the buildchain when the use-case is trivial
 and including Composer adds a dependency we do not control.

 3. '''To use a Composer-generated autoloader''' - This is what I '''have
 been objecting to'''. The Composer autoloader is designed to handle
 effectively any possible scenario, and for core and even plugins we have a
 very finite set of use-cases. Adding an autoloader that runs a lot of code
 for each class it loads adds unnecessary overhead on page load and makes
 XDEBUGging annoying. Plus, adding the autoloader is the trojan horse for
 the next point (#4)  and I am objecting upstream rather than later wish I
 had objected sooner. Constraints are your friends, let them be friendly
 here rather than throw in the kitchen sink that comes with Composer.

 4. '''To bundle Composer with WordPress core''' - I also '''strongly
 object to this'''. This adds '''an external dependency''' to WordPress
 that can break backward compatibility in the future.  Remember the fun
 that jQuery has given us? ''(And '''Rarst''', this is the scenario which I
 believed you had written that Composer was not a good fit for.)''

 5. '''To manage plugins and themes with Composer''' - This I probably do
 not need to object to because this is clearly '''the wrong tool for the
 job'''.  Composer is a static build tool, and plugins and themes are added
 and removed dynamically.

 6. '''By WordPress professionals to build and manage website projects''' -
 Yes!  '''This is where Composer really shines'''.  ''(And '''Rarst''' this
 is the use-case for which I understood you to be an advocate.)'' But it is
 better IMO to allow the developer to incorporate the latest version of
 Composer than to bundle a version with WordPress that might be out-of-
 date.

 7. '''By plugin and theme developers to manage their dependencies''' -
 '''Yes and No'''.  If their dependencies are the developer's '''own
 libraries, then yes''' ''(But even here, not a WordPress core-bundled
 version but instead let the plugin/theme developer build their own
 toolchain.)'' OTOH if the dependencies are PHP libraries from
 '''Packagist.org then no''' because there is no way to be sure that some
 other plugin is not also using the same PHP libraries and pulling in
 incompatible versions between the plugins.

 Hopefully this numbered list of use-cases clarifies and can provide a
 basis for which to discuss moving forward.

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