Simplified way to author PowerShell resources for DSCv3

Summary of the new feature / enhancement

The feedback from customers is that authoring class-based resources is too complex and script-function resources require a MOF schema. Although we will continue to support existing script-function and class-based PS resources, we should consider them legacy and only via PSDSC module (with eventual 3.0 release). This also means legacy resources will never get support for export, for example.

This proposes a new way to author DSCv3 resources in PS that does not require PSDSC module and instead is part of the PowerShellGroup resource and does not require authoring JSONSchema.

A goal is to not require any changes in PS itself to make this work so this will also work for WinPS5.1.

Proposed technical implementation details (optional)

The new PS resource model will be a module with cmdlets for get, set, test, export. The mapping will be defined in the .psd1 within a PrivateData section specifically for DSC. This means that these resources will still be discovered via $env:PSModulePath.

Most cases where the JSON structure is flat, the type and constraint information will simply be directly mapped to the parameters of a cmdlet. The PowerShellGroup resource will handle validating the input JSON maps to the cmdlet parameters.

In some cases, the input JSON may require nested objects. To accommodate this, there are several options:

• require a PS class to define the nested object
  • the advantage here is that the current syntax is sufficient, but requires authoring a class which was one of the complaints and testing would have to be within module scope to access the class
• use another PS function to simply define the object and in the actual get, etc... cmdlet have the parameter name match the "type" function name which simply accepts a hashtable
  • this approach is a bit hacky, but testing would be easy if the "type" function just returns a hashtable using the parameters as properties. Deeply nested objects would just follow the same design. Keys could be represented as parameters being members of a Keys parameterset.

Here's an example for a simple object:

{
  "name": "powershell",
  "version": "7.4.0"
}

In this case, a get could look like:

function get-powershell {
  param(
    [parameter(mandatory)]
    [string]$name,
    [string]$version
  )
}

If we change this to have a nested object:

{
  "name": "powershell",
  "version": {
    "major": 7
    "minor": 4
    "patch": 0
  }
}

Then the required function would look like:

function get-powershell {
  param(
    [parameter(mandatory)]
    [string]$name,
    [hashtable]$version
  )

  # when dsc calls this resource, it would pass a hashtable that looks like the one below for `$version`
}

function version {
  param(
    [int]$major,
    [int]$minor,
    [int]$patch
  )

  # this part wouldn't be used by DSC, but could be used for unittests
  return @{major=$major;minor=$minor;patch=$patch}
} 

No implementation file or test is named. Start by reading the PowerShellGroup resource and the proposed module manifest's PrivateData mapping, then compare discovery through $env:PSModulePath with existing script-function and class-based resources. Done requires an agreed resource model and corresponding validation, invocation, and export behavior, but the issue leaves key nested-object choices unresolved.