- π¨π¦Canada mandclu
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?
- π¨π¦Canada mandclu
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 moduleDo the maintainers (or anyone else) have a preference on the best path forward?
- π¨π¦Canada nedjo
@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 moduleMy 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 toFeaturesBundleInterface
. as is done in core per the relevant documentation β . Values would bemodule
andrecipe
. Perhaps we declare these in an Enum inFeaturesBundleInterface
. 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
module
in 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.