-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: separate out logic for setting value #26
Conversation
@shadowspawn all your assumptions seem sound in my opinion, and this refactor seems great 👍 |
Thanks for the feedback, I wasn't sure if I was overreaching. 😅 |
Tests updated. One of the tests did pick up a bug I introduced in the refactored code. 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks solid to me.
This PR got mentioned in the recent Tooling Group meeting: https://docs.google.com/document/d/1Jt4XANUsahEv7JRUZqtSF1XVKWWPW1AWIHylBxLPbpU/edit I'll wait for another review approval before merging, or the next meeting. Whichever comes first. 😄 |
This PR is in limbo with some of the spawned issues having changed the underlying code, and some of the changes at odds with original vision which has been freshly enumerated in #24 (comment) Maybe a success on both counts to move the project forward. 😅 Waiting for some clarity on whether to rewrite same PR on new base, or whether to split into subsets. (The refactor will clash with everything else, so I don't want both that and others in flight at the same time.) |
I'll start again and try and land the refactor first. |
The starting point of this refactor was separating the logic for how flags and values are stored from the parsing to address #19. In the process, I identified a couple of likely bugs with
=
handling.I took an interpretation of what should be stored in results for flags/values consistent with the new naming. (#13)
values
? #19)values
? #19)flags
(and not invalues
unless "multiple")values
(and not inflags
)a=b
is treated as optiona
with valueb
whether or not marked as "withValue" (Behaviour for zero config --foo=a ? #24)a=b=c
takes everything after first equals as value so value isb=c
(fixes bug)Possible Conventional Commit footers for commit comment (I have not used convention before):