Idea: allow Section.Option keys in the configuration hashtable

[nohwnd]

Summary of the feature request

Let a configuration hashtable use Section.Option as the key, so a short ad-hoc configuration stays on one line:

Invoke-Pester -Configuration @{ 'Run.Parallel' = $true; 'Output.Verbosity' = 'Detailed' }

# same as
Invoke-Pester -Configuration @{ Run = @{ Parallel = $true }; Output = @{ Verbosity = 'Detailed' } }

Purely a convenience, it adds nothing you cannot already do.

I proposed this before in #1265 (#1265 (comment)) and @fflaten said back then: "The shortcut dictionary syntax looks nice for ad-hoc, but not critical for me. I mostly use hashtable when writing tests for Pester itself to keep it short." I closed that RFC in 2024 without it. Bringing it back on its own so it can be decided rather than sit inside a closed RFC.

I am totally fine with not doing this, but I would like it discussed. @fflaten has your opinion changed?

How should it work?

The configuration is exactly two levels, section and option, and no option name contains a dot, so a split on the first dot is unambiguous. No recursion, no ambiguity to resolve.

One place to do it: the PesterConfiguration(IDictionary) constructor. Every entry point goes through that cast, so all of these would work at once:

• Invoke-Pester -Configuration @{ }
• New-PesterConfiguration -Hashtable @{ }
• [PesterConfiguration]@{ }
• $PesterPreference = @{ } in a test file

Before the section constructors run, walk the dictionary once, and for every key that contains a dot, move the value into a nested dictionary under the section name. Then hand the result to the existing section constructors, which do not change at all.

Assigning a single section ($config.Run = @{ Parallel = $true }) does not need this, there is no section name to write there.

Where it is actually useful, as far as I can tell:

• One-line runs in a terminal or a CI script, where nesting for one or two options is most of the typing.
• Our own tests. Frode's point above, tst/*.ts.ps1 builds configurations constantly.
• Settings read from a psd1 or JSON file, where flat keys are the natural shape.

Two things to decide:

1. What happens with @{ 'Run.Path' = 'x'; Run = @{ Path = 'y' } }. Throw, or let one win. I would throw, it is a mistake either way.
2. @{ 'Run.Paralel' = $true } is dropped silently, same as the nested form. That is Configuration hashtable silently drops keys it does not recognize #2975, and whatever we decide there should cover the dotted keys too.

🤖