fix: allow :build_type
to be specified in any order
#6
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.
Fixes #4
First off -- thank you for this plugin! What a game changer! Has been working out great.
This PR fixes a small logic bug that required
:build_type
to always be the first option.While iterating through the
|k,v|
entries ofoptions
, the intent was to only operate on:build_type
.Previously, the check was
next if not options.key?(Pod::UserOption.keyword)
("does :build_type exist?")This would be
true
even ifk
was not:build_type
, causing the wrong key to be operated on (unlessbuild_type
was first)This PR changes the check to
next if k != Pod::UserOption.keyword
, and I have verified that this results in the intended behavior.However, I'm not totally sure how to implement tests of this behavior -- I don't work in ruby very often. Happy to help with that if you have any guidance, though!
Thank you for reviewing!