-
Notifications
You must be signed in to change notification settings - Fork 472
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
Add semver.minVersion function. #241
Conversation
I've rebased / resolved the conflicts. |
I think there's an edge case missed here, which isn't likely to come up in practice, but is worth covering for correctness. If a version has a prerelease on it, and is a Consider the range I think this can be handled by having another Another interesting case is something like (If you had Also, it'd be good to have 100% coverage of new code, if possible, especially if it won't be exercised in npm itself. I haven't tested this directly. |
Good catch. I've added this.
I've added this specific test case and with the components in reverse (less than first and greater than first).
The only added code which is not covered is the default case which is unreachable. For now I've added the hint for istanbul to ignore it, I could remove the default case if you prefer. |
If it's truly unreachable, then yeah, just go ahead and remove it, or make it an ignored throw so at least we'll find out some day if it turns out that assumption is incorrect. |
OIC, I'd missed that, yeah, it just appends a |
I already added the hint for istanbul to ignore the throw, knowing if a new operator is added in the future seemed like the right way to handle this. That way if someone uses minVersion against a range with a new operator it'll throw instead of giving an incorrect result. |
Ah, yeah, a new operator in the future could result in that case being hit. Good call 👍 |
I understand time is short for all but can I do anything to help this move forward? |
No description provided.