How to prevent a site from ever using experimental core modules?

Question

Quote from Experimental modules in Drupal 8:

Drupal 8 core introduces the concept of experimental modules. These are modules that are provided with Drupal core for testing purposes, but that are not yet fully supported. Experimental modules are included in the Core (Experimental) package on the Extend page of a Drupal site (/admin/modules).

I do understand what "testing purposes" means, and I'm aware of best practices like having a Dev / Staging / QA / Prod configuration.

But when using Drupal 8 in a Prod environment, I'm looking for a way to ensure to a site owner something like "You can be 100% that there is no way that any of these experimental modules can ever be enabled in the prod version of your site.". Imagine it's about a business critical Drupal site where "testing in production" is not ever allowed.

So what options do I have in Drupal, apart from hacking core (which is not an option), to be 100% sure of this? And so that:

• It applies for "everybody" (any user), so even user/1 should not be able to do so if (s)he'd be tempted to do so.
• It doesn't matter if you're using the Admin UI, Drush, Console or anything similar

Update

There are some D8 core issues about these experimental modules, which IMO are either related, or contains some inspiring comments for finding a possible solution (work around?):

• Remove experimental modules from core (or treat them like first class modules).
• [meta] No definition of "Experimental" & not nearly enough warning, with proposed solutions detailed in these related issues:
  • Experimental modules should have their own version numbers.
  • Use a confirmation form when enabling experimental modules.
  • Provide a link to the experimental module policy in the status report warning.
  • Warn about experimental modules on their help pages.

Answer 1

This is by far not as black and white as you make it in regards to experimental modules.

First, on a mission critical production site, you don't want to do anything directly on production. Completely irrelevant then if it's an experimental module or not. Any configuration change or module should be tested first. There are modules to enforce a read only configuration system for example, that's one way to approach that. One example is Configuration Read-only mode, note that I have no personal experience with it.

Second, there are experimental modules and there are experimental modules. The first experimental module apart from migrate, wich is a special case anyway, was big_pipe. Which is now officially stable in 8.3. It is a module that has zero data, zero API, zero configuration, zero UI. You just enabled it and it does its thing. As such, it was perfectly fine to use it on production already and people have been doing that, myself included. After testing it first, like any other module/functionality. If you found a bug, you could disable it from one minute to the other, without loosing any data or critical functionality.

On the other side of that spectrum is content_moderation and anything around that. Once you start using it, it is a critical and central part of your content creation workflow, and getting rid of it again is much harder. We specifically made it so you could uninstall it, and your content that was published was still published and same for unpublished. But your workflows and metadata around that would be gone. Also upgrading is likely going to be tough from 8.2 to 8.3. That's also why we're working hard to get media_entity into core as a non-experimental module, so people have a stable API and data storage that they can rely on.

Third, the concept of experimental modules is pretty new and there's a bunch of modules in core that we would have made experimental if we could have back when they were added. rest.module and the related modules is one example there.

And last, lots of contrib modules are at least as experimental as experimental core modules, they just don't warn you about that in such an obvious way. Especially development/pre-beta versions. They just don't warn you about themself in such an obvious way.

To summarize, as with many other things, you need to do your research about an experimental module before using it, and for example check if it's big_pipe-like or content_moderation-like. And then decide what that means for your site.

Answer 2

I am not 100% sure about this, but I think the only bulletproof way is to

• Extend ModuleHandler or implement your own ModuleHandlerInterface class, and exclude experimental modules from the methods. Then replace the @module_hander in the service container.
• Extend ModuleInstaller or implement your own ModuleInstallerInterface class, and exclude experimental modules from the methods. Then replace the @module_installer in the service container.
• Implement a hook_system_info() to remove experimental modules from the discovery list.

Answer 3

Wanted to delete this, but going to leave this undeleted for the comments sake.

Option 1)

Don't give client the Administer modules permission and don't give them user 1.

Option 2)

Custom module with hook_form_alter that loads the CSS or JS file which hides those rows.

EX:

jQuery to hide the table row that belongs to a experimental module.

(function ($) {

    $('tr').each(function() {

       var module_attr = $(this).attr('data-drupal-selector');

       if (module_attr == 'edit-modules-content-moderation' || 'edit-modules-datetime-range' || ...) {

         $(this).hide();

       }
    });

}(jQuery));

Or you can hide them all with

$('#edit-modules-core-experimental').hide();

or

CSS #edit-modules-core-experimental { display: none; }

Also add a validate function in case the client strips the CSS/JS or checkmarks the value via inspect element.