Enable passing JSON input properties as args to resource #1475

Activity

1. Steve Lee (SteveL-MSFT)

   added

   Issue-EnhancementThe issue is a feature or ideaThe issue is a feature or idea

   Needs Triage

   on Apr 9, 2026
2. michaeltlombardi commented on Apr 22, 2026

   

   Mikey Lombardi (He/Him) (michaeltlombardi)

   on Apr 22, 2026

   Collaborator

   More actions

   I would strongly prefer we limit the dynamicism of resource manifests as much as possible. The more we support use of expressions in the manifest:

   • The less we can rely on JSON Schema for validation/IntelliSense. This will eventually require a language server / extension for authoring DSC manifest files to provide a good developer experience.
   • The more difficult it becomes for higher order tools to integrate with resources. They need to understand not only the JSON schema but any supported expressions.
   • The more difficult it becomes to scan and understand a resource manifest. Static analysis is more difficult and must be expression-aware.
   • The more complex guidance becomes for resource authors as we need to address what sorts of values and expressions can be used.

   For resource authors wrapping existing software that doesn't handle JSON input, like the example in this issue, I would probably expect a resource author to provide a minimal script that wraps the invocation to provide better ergonomics and map the behavior of the tool to DSC's semantics.

   For resource authors who own the tool they want to make available as a DSC resource, I would expect that they either provide an explicit interface command for DSC or optionally support JSON input, such as:

   # non-DSC commands
   tstoy group add --name foo --description "foo group"
   # DSC-compatible commands
   tstoy group get --name foo
   '{"name": "foo"}' | tstoy group get -
   tstoy group get --input-json '{"name": "foo"}'
   
   tstoy group list
   tstoy group list --filter '{"name":"f*"}'
   
   tstoy group remove --name foo
   '{"name":"foo"}' | tstoy group remove
   
   tstoy group set --name foo --description "foo group"
   tstoy group set --desired-state '{"name":"foo","description":"foo group"}'

   I would generally recommend that resource authors wrapping external commands they don't own to provide a script. While passthrough as described in this issue works for relatively simple contexts, I suspect it will lead to more difficulties for testing, logging, and so on. to me, it feels like a transitive design for a resource more than a mature production-ready option.

   I would strongly recommend that resource authors who own the software they're writing a manifest for update their CLI to provide first-class ergonomics for their non-DSC users and fully participate in the semantics of DSC with specific commands (or command flags).