DSC Feature Flags / Optional Units

[Trenly]

Description of the new feature / enhancement

When writing a DSC file, there may be both common workflows (the ideal use case for DSC) as well as optional workflows that may be necessary for various development areas. Take winget-dsc as an example - users working on any DSC resource in that repository will need some standard set of tools, which are currently installed by the configuration.dsc.yaml.

If working on the NpmDsc resource, then Node.js should also be installed. However, not all contributors will be contributing to that resource and may not want Node.js installed if it is not necessary for their contributions. The same could be said about Python - users may already have a specific version installed and not want the latest, or may not want Python at all, if they are not working on that DSC resource.

It would be beneficial if there were a way to specify steps in a DSC yaml file as optional. Inspiration could be taken from Rust's features implementation, where the defaults can be set by the author of the resource, and consumers can use --no-default-features to disable all optional configuration units, and/or --features [<feature>] to enable specific optional modules if they are not specified as a default feature

Proposed technical implementation details

No response

[denelon]

Parameters can be used in the latest (DSC v3) configuration schema to handle some of this, but I hadn't thought about the use of parameters to drive optional pieces of a configuration. I think this warrants some discussion in terms of what WinGet would show for the configuration to be run and how to reason about conditional behaviors in a configuration.