Issue #3615015: Document the public API surface for dependent modules

Downstream modules had no way to tell which parts of myrest they were allowed to build on, so any refactoring risked breaking them silently.

Audit of the modules in this codebase:

  • myrest_metatag couples to one symbol, MyrestMetatagProviderInterface, plus the myrest_metatag_provider service tag. Its .info.yml declares myrest:myrest correctly, but its composer.json has no require section, so Composer never pulls myrest in. Tracked in that project.
  • myrest_seo reports the same because that checkout currently holds a copy of the myrest_metatag code. It has to be untangled first.
  • myentity does not depend on myrest; the dependency runs the other way.
  • commerce_back_in_stock is not present here and was not audited.

The constructor changes from issues 27 and 29 break nothing downstream: no dependent module extends or instantiates those classes.

Changes here:

  • README gains a "Public API for dependent modules" section listing the supported extension points, and states that the normalizer, the event subscribers, the path processor, the authentication provider, the settings form and the resource plugins are implementation detail.
  • README documents the .info.yml plus composer.json declaration pattern and why a module needs both.
  • Mark the 12 infrastructure classes @internal so the boundary lives in the code rather than only in the README.
  • Add the missing trailing newline to the two filter plugins touched.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Closes #3615015

Merge request reports

Loading