[META] Decouple modules from Thunder

+1 for making access_unpublished and content_lock optional.

It would be also a good thing if any media_entity_* submodule, which adds a new media bundle, could be optional. Especially the more specialized ones, e.g. media_entity_pinterest, media_entity_twitter and media_entity_instagram.

Please do also add some modules only as suggestions in Thunder's composer.json file (e.g. fb_instant_articles), so you won't run into trouble when another version is required in your project.

Thanx!

• responsive_preview (required by Thunder Liveblog)
• database logging (required by Thunder Liveblog)
• internal page cache, internal dynamic page cache (required by Thunder Liveblog)
• metatag facebook, open graph, twitter cards (required by Thunder Article)
• simple_sitemap (required by Thunder Liveblog)

@Andre-b: none of these are required by Thunder Liveblog, what do you mean?

@hctom, this is a tough one, in the end we would only have suggestion (which would be pointless), since there could always be a different major version of any module.

@daniel.bosen Okay, but what about things like fb_instant_articles, amptheme etc. Those are not required at all by any Thunder component, but may be used to extend Thunders functionality. So I guess those should definitely be loose coupled.

There are a few different kinds of dependancies, which all have to be treated differntly:

1. Dependencies in the profile itself (thunder.info.yml)
2. Dependencies from modules in the distribution, which are either:
   • Non optional modules which are part of the distribution (thunder_article, thunder_media, thunder_taxonomy, thunder_updater), or
   • Optional dependencies, which are disabled by default (thunder_demo, thunder_fia, thunder_liveblog...)
3. Dependencies from configuration

Case 1) is simple, those dependencies can easily be disabled.
Case 2) Hard dependencies from non optional could simply be moved to the distribution, and could be disabled afterwards. Dependencies of optional modules are harder to work with. If they are to be disabled, they would have to be enabled in install hooks (as soft dependencies)
Case 3) Configuration is a bit harder. Putting it into optionial helps at times, but not if we wish to provide tight integration of some features.
One example is the content lock modul. We provide a content view, this view should contain the locking information, when content lock is enabled, but the same view should also be shipped without the content lock menu. In those cases we would also have to programatically change the configuration in the install/uninstall hooks.

With this in mind, I propose to do stuff in the following order:

1. move dependencies from non optional modules to the distribution
2. use install hook in optional modules to enable sub dependencies
3. carefully decide, which configuration could simply be put to optional
4. handle more problematic configuration as needed

I would like to keep composer stuff out of this ticket, @hctom, please create a new ticket for discussing this topic.