Support generating recipes

I'd be interested in helping with this, but I'm not very familiar with how Features works under the hood. Could a maintainer point me in the right direction on where to start?

+1 to provide submodule to export as recipes

Poking around in the code a little, it seems like the logical place to start would be in the addPackageFiles() method of the FeaturesManager class. I can see some potential approaches to making these changes:

1. Overwrite the current method and assume that recipes are the way forward (probably only acceptable if this would be the basis of a new major version)
2. Put code into a submodule that would decorate the current FeaturesManager class
3. Add some kind of global configuration option to export recipes instead of standard modules
4. Add a per-feature option to export a recipe instead of a standard module

Do the maintainers (or anyone else) have a preference on the best path forward?

The module can just decorate FeaturesManager

@mandclu If you happen to still be interested and available to start on this, I have some availability in the next few weeks to provide review and comments. While I'm not a current maintainer, I am a past one and have a good familiarity with the code.

I'll start by commenting on some of what may be needed.

At a high level, we have the advantage that we already model features fairly generically as a set of "packages", see the Package object and its properties. Currently, to generate feature modules, we parse these packages into modules. Our task here is to enable a second target format: recipes.

Packages are associated with a Features bundle, see the relevant documentation → and the associated FeaturesBundle config entity type.

Each package can have a set of configuration items assigned to Package::config.

In the current implementation, as you've noted, we parse the set of feature packages into extensions in FeaturesManager:: addPackageFiles(). We model most of the packages as modules, but optionally we special-case one package to be parsed as an install profile.

Regarding your question about approaches:

1. Overwrite the current method and assume that recipes are the way forward (probably only acceptable if this would be the basis of a new major version)
2. Put code into a submodule that would decorate the current FeaturesManager class
3. Add some kind of global configuration option to export recipes instead of standard modules
4. Add a per-feature option to export a recipe instead of a standard module

My personal take is: #3 is the way to go. Rationale:

• Recipes appear to be here to stay. If feasible, our best approach is to introduce recipe support directly in Features rather than through a submodule.
• The changes would be significant enough as to require a new minor release, but should be feasible within the existing major version. At first glance, it look like a lot of the work - possibly most - can be done within existing classes without deprecations. :: addPackageFiles(), for example, is a protected method that we're free to modify as needed.

So, yes, concretely, we'd start by adding a new property to the FeaturesBundle object--perhaps ::targetRenderFormat or similar.. We'd add accompanying getter and setter methods to FeaturesBundleInterface. as is done in core per the relevant documentation → . Values would be module and recipe. Perhaps we declare these in an Enum in FeaturesBundleInterface. We'd need:

• At the UI level, a new radio element on the bundle configuration form to manage the new setting.
• An update to set the value to modulein existing bundle configuration.

From there, we can get a general sense of what's needed by looking look at our two different target formats - modules and recipes - and highlighting (a) how they differ and (b) how the parsing to modules is currently handled in Features (so we know where changes are needed). I'll give that some thought and follow up when I can with some further notes.