Problem/Motivation

Experimental modules have been used to successfully introduce new features in Drupal core. In the case of SDC, the transition from beta module to stable feature was quite tedious #3352256: Move code from the experimental SDC module to core.

The core mailer project did take a different approach because of that experience. An alpha level experimental module was committed to core, but it only contains the services yml file. The implementation itself is placed directly into lib/Drupal/Core/Mailer. As a result, those classes do not need to be renamed when the experimental module transitions to a stable feature.

This approach could be streamlined by not requiring a module at all. The services yaml file of an experimental feature could be placed somewhere in the source tree. In order to enable that feature, users need to add the path to that file via container_yaml setting. This approach is explored in #3542264: Rename mailer module to mailer_symfony and avoid namespace conflict with contrib mailer module

Steps to reproduce

Proposed resolution

Add policy documentation for this approach.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

znerol created an issue.

alexpott’s picture

Thanks @znerol for creating this issue. Nice one. FYI Also recipes never had a module either.

I think it is a really good idea to not have a module is the end goal is not introduce a module.

cmlara’s picture

#3423352: Add an API for feature flags proposes adding an API for implementing feature flags.

xjm’s picture

I think this is sort of a dupe of #3423352: Add an API for feature flags, or maybe a parent meta. We've used modules in the past even when the code is targeted for core/lib (etc.) in order to have a clean way to remove code from the alpha branch before we are ready to make API or security commitments for it. Core does not have a means for us to support this currently without using an extension, because the extension system already has experimental flags, a contained codepath to remove, etc. So we would need API to implement it in a different way.

znerol’s picture

I think this proposal has a similar goal as #3423352: Add an API for feature flags but it tries to achieve it with a policy addition alone. I cannot tell if that is viable though.

znerol’s picture

Or maybe with a minimal API addition: Could recipes be extended to provide a services.yml? That would cover the needs of experimental mailer I guess.

znerol’s picture

Maybe recipes are not a good candidate as long as #3333076: Support reverting a recipe isn't resolved.

alexpott’s picture

@znerol I wasn't talking about individual recipes but the recipe API. That was added without an experimental module.