[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 schlessera):

 Replying to [comment:180 JohnPBloch]:
 > Replying to [comment:167 rmccue]:
 > > I still think this seems to be a solution (Composer) searching for a
 problem.

 > I've spent the long weekend mulling over this and really thinking about
 it and at this point I think you're mostly right. We've already figured
 out that stock composer out of the box is not a solution that fits core's
 needs very well.

 I fail to see in what way it does not fit. Just using it (without making
 changes to account for broken plugins) is a matter of a handful of lines.
 A handful of lines that make a huge leap forward to close some of the gap
 that has formed between WordPress and PHP development.

 > It's flexible enough that plugins could make it fit, sure, but at that
 point, we've almost definitely over-complicated things and need to ask
 ourselves why we're shaving this darn yak in the first place.

 Still, I can't really follow. Maybe I'm just not intent enough on
 "preserving ways of the past".

 - "use existing mature library" vs "design, create and test own library,
 with runtime classes, CLI commands, etc..."
 - "point to Composer documentation" vs "create new sections in developer's
 handbook"
 - "use existing deployment tools" vs "creating/adapting WP-specific
 deployment tools"
 - ...

 I fail to see how using Composer is more complicated than recreating an
 entire "ecosystem" from scratch.

 > I still think it would be useful to use composer eventually, but this is
 mostly because I'm thinking of the possible uses for, say, adding dev
 dependencies like a specific version of phpunit, etc. However, such use
 cases are clearly out of scope for this ticket.

 Yes, they are out of scope, but they are possible today, without any
 additional changes...

 > Besides, a home-grown autoloader now does not necessarily preclude using
 composer down the road if it starts to make more sense later,
 ''especially'' if we're careful about what the integration points look
 like for 3rd party code.

 I would agree if we were talking about a semantically versioned project
 with regular update cycles. We're talking about WordPress here, though,
 with a BC philosophy that transforms everything that enters the codebase
 into technical debt eventually (excuse the overly harsh words here, it is
 meant to bring a point across, not to offend people).

 > @schlessera @TJNowell What are your thoughts? you know how much I would
 love to use composer; but isn't it starting to seem to you that the work
 spent bending composer into a WP shape would be better spent sculpting WP
 into something a tiny bit more composer-shaped?

 As I have been doing several test versions, and created a custom Composer
 plugin to meet additional WP needs
 (https://github.com/staylor/develop.wordpress/pull/1), I still don't
 really agree with such an assertion. The way I see it, the only "bending"
 that has been done is to adapt to outdated PHP versions (5.2-compatible
 class map), broken plugins (case-insensitive class names) and a too rigid
 file layout (using ABSPATH, which is even optional, as it worked without).
 And still, Composer just coped with it with half an hour of work.

 So, what is this bending and over-complicating all about? Because I sure
 seem to find the creation of an autoloader design from scratch far more
 complicated than what we've done so far... The current ticket is just full
 of arguments that have nothing to do with Composer or not-Composer. A lot
 of them are just : "yes, but we like it as it was before...".

 And once again, I want to clarify, we are talking about using Composer at
 build-time (which can be completely automated by including it into the
 grunt pipeline => 0 complexity) and using the generated class-map to be
 able to start refactoring the code base in hopes of making it more
 flexible (100s requires out, one require in => 0 complexity). Yes,
 changing the code base so that it makes better use of the autoloader might
 be complicated, but that has nothing to do with Composer. It is just a
 refactoring that is long overdue, and that will be necessary with a custom
 autoloader as well.

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