[wp-trac] [WordPress Trac] #47256: Use composer to install and update external PHP libraries

[WordPress Trac]

#47256: Use composer to install and update external PHP libraries
-------------------------------------+-----------------------------
 Reporter:  spacedmonkey             |       Owner:  johnbillion
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Future Release
Component:  Build/Test Tools         |     Version:  5.2
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-refresh  |     Focuses:
-------------------------------------+-----------------------------

Comment (by mmorris8):

 Pointed to this ticket by @westonruter

 Parallel to the core is how composer's availablity affects plugins.
 Currently plugins that make use of composer libraries have to ship the
 code with their distribution, which is not idea.

 Worse, to prevent conflicts with other plugins that may use the same
 libraries plugins must "monkey type" those libraries using tools like
 Strauss ( https://github.com/BrianHenryIE/strauss ) which is again not
 ideal as such programmatic namespace reassignment can introduce bugs.

 Third problem, two plugins wanting to use different incompatible versions
 of the same library. A policy will need to be in place when such a
 conflict arises as both the plugins cannot be active at the same time.
 There's also the tricky situation where both the plugins need to be
 updated together so that they both are using the same dependency.

 Fourth - Plugins that are shipped as composer libraries are going to live
 in the composer vendor library, not in the current plugin directory. This
 could cause trouble for custom setups that shuffle plugins around from the
 default location. Having plugin code in three locations (including mu-
 plugins) instead of two is a consideration. Maybe not a problem, but it is
 a change worth nothing.

 A plugin that is packaged as a composer library likely has little to no
 need for the traditional root file except for writing hooks. Those,
 strictly speaking, only need the hooks to be invoked and that could be
 moved into their package.json file. Composer will ignore attributes in the
 package.json it doesn't recognize, so we could extend that definition to
 include hooks like this

 {{{#!json
 {
   "hooks": [
     { "activation": {"ExamplePlugin\\Installer", "activate"} },
     { "deactivation": {"ExamplePlugin\\Installer", "deactivate"} },
     { "uninstall": {"ExamplePlugin\\Installer", "uninstall"} }
   ]
 }
 }}}

 That isn't going to be executable, but executable PHP code can be
 generated from it. The install process could maintain such a file.

 I was around for the testing of the Drupal integration of composer back in
 the day, and the problems faced there will surface here. Some of the same
 solutions will apply, and some will require new solutions. I'm willing to
 help with this and think I do have enough experience for this.

 Before writing further implementation though I think a discussion on goals
 and scope is warranted. Plocking in composer to handle some core libraries
 without giving any thought to how that will affect the theme and plugin
 ecosystem is a patently bad idea. If composer is brought in there will
 need to be core code that handles dependency management issues beyond
 those composer can handle.

 In short, if this is carefully thought out and done it will be a massive
 win. Mishandle this and it's going to be a disaster.

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