Library infrastructure for MediaWiki

Rationale
Our long term goal is to make MediaWiki an application that is composed of many small purpose built libraries (internally and/or externally developed) with interfaces that allow individual libraries to be exchanged for others. Using this flexibility, allow easier tuning of major features for various use-cases and easier development of new large features by composition. For example, a (far) future project might replace storage of revisions as exists now with some system that has better performance characteristics for the Wikipedia wiki farm simply by configuring an alternate implementation of the revision storage library rather than including two implementations and branching logic in the MediaWiki codebase.


 * Make life better for new (and experienced) developers by organizing the code into simple components that can be easily understood.
 * Reverse inertia toward ever expanding monolithic core by encouraging developers (in core) to develop their work as reusable modules with clearly-defined interfaces
 * Start making true unit testing of core viable by having individually-testable units
 * Provide an interim step on the way to service-oriented architecture in a way that is useful independently of that goal
 * Encourage reuse and integration with larger software ecosystem. Done correctly, this will provide a useful means of expanding our development capacity through recruitment of library authors eager to showcase their work on a top 10 website.
 * Share our awesome libraries with others and encourage contributions from them even if they aren't particularly interested in making our sites better.

Out of scope
Complete breakup of MediaWiki core into components.

The end goal is not to eliminate MediaWiki but instead to make MediaWiki the platform for creating massive multi-user versioned data-based projects, and make it a platform that is flexible enough to extend in novel ways.

FY2014-15, Q2

 * Complete implementation and deployment of Structured logging RFC
 * Introduce Composer library management to MediaWiki's core git repository
 * Introduce git repository to manage libraries for WMF cluster deployments
 * Introduce PSR-3 logging interface to MediaWiki
 * Introduce optional external library (Monolog) to implement PSR-3 interface


 * Complete work for Composer managed libraries for use on WMF cluster RFC
 * Document use of Composer for library management
 * Procedures officially approved by architecture, security and operations groups
 * Implement monitoring tools to track security vulnerabilities in external libraries


 * Extract one component from MediaWiki, publish as a stand alone library and re-import to MediaWiki via Composer
 * Establish guidelines for git hosting, issue tracking and community management for independent libraries
 * cssjanus
 * cdb


 * Create list of future candidates for library extraction projects


 * Investigate implementing a library management system for JavaScript libraries used by MediaWiki
 * Discussions with the Frontend standards group concluded that at this time the future of Resource Loader and the general javascript package management space are too uncertain to commit to implementing automated javascript package management for MediaWiki. They would however like to participate in discussions of standards and practices for creating or extracting libraries and ensuring they are properly managed as independent or at least semi-autonomous open source projects. The group would like to revisit this topic in 3-6 months when currently active discussions about the future feature set of npm have been resolved. See meeting minutes for additional details.
 * Discussions with the Frontend standards group concluded that at this time the future of Resource Loader and the general javascript package management space are too uncertain to commit to implementing automated javascript package management for MediaWiki. They would however like to participate in discussions of standards and practices for creating or extracting libraries and ensuring they are properly managed as independent or at least semi-autonomous open source projects. The group would like to revisit this topic in 3-6 months when currently active discussions about the future feature set of npm have been resolved. See meeting minutes for additional details.

Documents

 * Phabricator project (board)