Core Platform Team/Initiative/Reduce Extension Interface Surface Area/Initiative Description

Project Leads
Product: Cindy Cicalese

Engineering: TBD

Current state
Planning

Expected start
FY1819 Q4 - FY1920 Q1

Summary
Currently, extension code is very highly dependent upon MediaWiki core code. If a change is made to the parameters passed to a hook or the public interface to any of the core PHP classes, for example, it is likely that extension breakage will occur.

This project will reduce the level of dependence of extensions upon MediaWiki core code by reducing the breadth of the interface through which extensions access MediaWiki core.

There are three mechanisms that have emerged over time by which extension code and core code interact:


 * 1) Extension code can be registered with the Extension Registry so that the extension code will invoked during execution of core code. Code of this type falls into four broad classes: action hooks, filter hooks, handlers, and services.
 * 2) Extension code can directly call any public core function to which it has access.
 * 3) Extension code can call core code through a web API (action API or REST API). This is usually done from JavaScript to add dynamic behavior, but can be done from PHP as well. (This mechanism is out of scope for this project as it is covered by another project.)

This project will examine each aspect of the first two mechanisms listed above to do the following:


 * 1) Analyze current usage
 * 2) Propose improved interfaces with reduced surface area (RFCs, as necessary)
 * 3) Create deprecation and migration plan
 * 4) Incrementally, for each new interface:
 * 5) implement new interface
 * 6) document new interface for extension developers
 * 7) deprecate old interface
 * 8) migrate extensions to new interface

Significance and motivation
This project aims to reduce the surface area of the extension interface so that the scope of changes to core that will affect extensions will be reduced. This will enable core developers to more confidently make changes to and improve core while reducing the need of extension developers to frequently react to changes in core that break their extensions. Constraints put on extensions by this new approach will yield dividends in the increased stability of the interface between core and extensions.

Milestones and major tasks

 * Develop the product plan
 * Analysis and Design:
 * Action and filter hooks:
 * Approve RFC for action and filter hooks
 * Enumerate all current hook points, and analyze their usage in extensions
 * Map current hooks to action and/or filter hooks
 * Access to core:
 * Analyze which core code is called by extensions
 * Analyze what global state is accessed by extensions
 * Identify areas of improvement for access to core
 * For each area of improvement identified:
 * Make proposal for improvement (possible RFC)
 * Collect feedback from stakeholders
 * Develop deprecation and migration plan
 * Create development plan
 * Development:
 * Implement the action and filter hook interfaces dictated in the RFC
 * Document migration steps for new hooks
 * Migrate extensions to new hooks
 * Implement new core interfaces per each proposal for improvement
 * Document migration plan for new core interfaces
 * Migrate extensions to new core interfaces
 * Deprecate then remove old hooks and interfaces

Outcome
Reduce complexity in core

Baseline

 * Number of hooks exposed to extensions: TBD
 * Percentage of APIs exposed to extensions: 100% of the code base

Target

 * TBD
 * TBD

Methodology and rationale
To measure success, we need to survey extension code and produce reports about 2 metrics:


 * The number of hooks points exposed to extensions
 * The number of APIs exposed to extensions

Time and resource estimate
TBD

Dependencies
TBD

Collaborators and stakeholders
TBD

Open questions

 * How should an extension expose a web API?
 * How do we annotate source code so that code is public or private to extensions?
 * Should Wikimedia and third party extensions have the same interface into core?
 * How close can we come to killing all global state, replacing it by using service locators?
 * Should there be a restricted service locator that extensions are forced to use?
 * Can the internal tag be used to mark certain classes as internal without making it difficult to work within core

Phabricator
TBD

Plans and RFCs
RFC: MediaWiki 2018 extension interfaces