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

 Replying to [comment:75 jorbin]:
 > Do we have anything to worry about if plugins are using composer or the
 5.2 autoloader?

 I know for sure that Yoast SEO uses it. The only conflict that is likely
 to happen is that the plugin would have to use the
 `xrstf_Composer52_ClassLoader` class from core. The "real" autoloader
 class has its name generated using `md5( uniqid() )` as a suffix, so
 there's an extremely low likelihood of a collision occurring between core
 and plugins. That being said, the core package could manually set the
 suffix by defining it in `config.autoloader-suffix` of `composer.json`. In
 short, I really don't think it's something to worry about. The
 `xrstf_Composer52_ClassLoader` class is loaded using an autoloader to
 begin with, so it won't get accidentally included twice (unless someone is
 REALLY doing composer the wrong way).

 > Is there a string we can grep the plugin repo for so we can alert any
 plugin authors?

 `class xrstf_Composer52_ClassLoader`

 > I added the `composer.lock` file in my patch.  Was there a specific
 reason for not including it before?

 I can't speak for @wonderboymusic but I would suggest keeping the `.lock`
 tracked in version control so that contributors can be assumed to be using
 the correct version of any given dependency.

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