Upgrade spectre.console to 0.47.0, modifying the Cake codebase to fix a breaking change this new version includes #4236
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fully addresses #4157, which was preventing spectre.console from being upgraded to 0.47.0. The PR also includes the actual upgrade to spectre.console 0.47.0
The approach taken is very similar to a previous Cake.Frosting issue, which has already been fixed: #3291
This PR follows the same pattern introduced for the fix, which was located in Cake.Frosting.Internal.DefaultCommand, here:
cake/src/Cake.Frosting/Internal/Commands/DefaultCommand.cs
Line 82 in c3cd2af
Within Cake proper (rather than Cake.Frosting)... Cake.Commands.DefaultCommand.Execute(...) has been modified to explicitly create the CakeArguments from CommandContext.Remaining, adding in the DefaultCommandSettings.Recompile flag, if necessary.
This PR has indirectly resulted in a move towards to using
CakeArguments
rather than the spectre.consoleIRemainingArgument
, which seems a lot cleaner and self-contained.Full disclosure: I'm a little uncomfortable submitting a PR with no unit tests, however my reasons for doing it are as follows:
DefaultCommand
, both Cake or Cake.Frosting ones, have entirely zero unit tests (rather, they seem to represent the top level container, and as such aren't tested)However, and relevant to both Cake and Cake.Frosting DefaultCommand's, I would consider introducing tests for this argument handling behaviour, if deemed necessary.
[It might be some kind of factory to create the
CakeArguments
, added into the IServiceCollection, and injected into the DefaultCommand, two versions of factory I guess, one for Cake and one for Cake.Frosting (given both commands have different DefaultCommandSettings classes). But that's just some thinking off the top of my head]