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
There are three mechanisms 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. This includes several types of code that might be registered including: hooks, content handlers, services, API classes, and special pages.
 * 2) Extension code can directly call any public core function, extend any core class, and access core global state.
 * 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.

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, it is likely that extension breakage will occur. This project will improve that situation, primarily focusing on the first two aspects above, since the third is covered by another project.

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.

Milestones and major tasks

 * Develop product plan
 * Approve RFC for action and filter hooks
 * Enumerate all hook points, and analyze their usage in extensions
 * Map current hooks to action or filter hooks
 * Analyze which core code is called or extended by extensions
 * Analyze what global state is accessed by extensions
 * Define narrow programmatic API that core exposes to extensions
 * Collect feedback from stakeholders on programmatic API
 * Approve RFC for new programmatic API
 * Develop migration plan for old extensions
 * Implement backward compatibility shim
 * Implement new action and filter hooks and new programmatic API
 * Migrate extensions to new hooks and API
 * Deprecate old hooks and API

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

Baseline

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

Target

 * TBD
 * TBD

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?

Phabricator
TBD

Plans and RFCs
RFC: MediaWiki 2018 extension interfaces