[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 dnaber-de):

 Nice to see, that things move. Thanks for all your effort on this. However
 I'm wondering what is the main goal left on this ticket? The original
 intention was to have a single, ''dynamic'' autoloader instance provided
 by the core that can be used by plugins. That's obviously deprecated by
 the concept of using composer to build an autoloader (which I agree with,
 don't get me wrong).

 In the end it should be our goal (not necessarily of this ticket) to be
 able to use WordPress as a composer package and leave the autoloader
 management of the complete app to composer to have one central autoloader.

 The current `composer.json` defines the developer repository
 (`git://develop.git.wordpress.org`) as type `wordpress-core`. But popular
 installer configurations out there assumes that the build repository is of
 type `wordpress-core` (the structure of `johnpbloch/wordpress`). I don't
 think this as a tough problem, installer scripts can be adapted to the
 structure of this new and original `wordpress-core` package.

 However, we should leave the `composer.json` in the root of the repository
 and should not move it to `src/` as suggested by [comment:90 swissspidy]:

 > Having the `composer.json` file inside `src` solves this. `wp-
 includes/vendor` would probably make ideas like #31744 easier.

 Replying to [comment:58 JohnPBloch]:
 > Replying to [comment:57 jorbin]:
 > > If the solution is going to include a composer file, related: #23912
 >
 > I think that ticket is only tangentially related to this one. This
 ticket introduces a composer.json file as a development tool in service of
 building a release package, whereas that ticket is more about introducing
 composer.json in the built package so as to add support for using the
 built package in non-core contexts.
 >
 > I'd love to see that other ticket move forward too, but I think each of
 these can move forward independently of one another.

 In this case we should discuss both package name and type of both
 repositories. But as suggested above, the best way would be to use the
 developer-repository as composer package and adapt installers to this
 structure than providing two packages with two autoloader configurations
 and thus, two different build processes.

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