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_typeto 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
trueeven ifkwas not:build_type, causing the wrong key to be operated on (unlessbuild_typewas 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!