Handle boolean flags #30
Conversation
Codecov Report
@@ Coverage Diff @@
## master #30 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 1 1
Lines 64 78 +14
=====================================
+ Hits 64 78 +14
Continue to review full report at Codecov.
|
|
@jridgewell I made some refactors to the code, mostly cosmetic and layout. Can you rebase? 👍 |
Not all options require an argument, but we treated everything (minus leading shorthands) that as needing one. The easiest way to demonstrate is with an example:
```bash
$ git push -f origin master
```
Here, `-f` doesn't take an argument, so returning `{ f: "origin" }` is definitely wrong.
I'm solving this by passing a `boolean` array into the parser. This is so we can support both the current and the boolean syntax:
```bash
$ curl -X POST ...
$ git push -f origin master
```
|
Rebased. |
|
@jridgewell Can you add these docs? For the API section. options.booleanAn array of options that should be parsed as booleans. getopts(["-f", "bar"], {
boolean: ["f"]
}) //=> { _:["bar"], f:true }OR
|
|
@jridgewell What do you think we should do about this edge case? const args = ["-a1"]
const opts = {
boolean: ["a"]
}
getopts(args, opts) // => { _: [], a: '1' }These kind of flags like |
|
I personally don't like the short splitting, I'd rather it always treats them as individual flags. So, I don't know what the correct behavior would be. What do the other parsers do? |
|
Alright, thinking about this some more, I think it should return |
|
@jridgewell Behavior is mixed and inconsistent.
Partially, mostly agree. We are not type casting values, which I prefer, so e.g., Still find the Thanks for adding this feature, it was on my todo list for a while. 🎉🎉 |
|
|
|
Truthy, I mean. |
Not all options require an argument, but we treated everything (minus leading shorthands) that as needing one. The easiest way to demonstrate is with an example:
```bash
$ git push -f origin master
```
Here, `-f` doesn't take an argument, so returning `{ f: "origin" }` is definitely wrong.
I'm solving this by passing a `boolean` array into the parser. This is so we can support both the current and the boolean syntax:
```bash
$ curl -X POST ...
$ git push -f origin master
```
Not all options require an argument, but we treated everything (minus leading shorthands) that as needing one. The easiest way to demonstrate is with an example:
```bash
$ git push -f origin master
```
Here, `-f` doesn't take an argument, so returning `{ f: "origin" }` is definitely wrong.
I'm solving this by passing a `boolean` array into the parser. This is so we can support both the current and the boolean syntax:
```bash
$ curl -X POST ...
$ git push -f origin master
```
Not all options require an argument, but we treated everything (minus leading shorthands) as needing one. The easiest way to demonstrate is with an example:
Here,
-fdoesn't take an argument, so returning{ f: "origin" }is definitely wrong.I'm solving this by passing a
booleanarray into the parser. This is so we can support both the current (by default) and the boolean syntax:$ curl -X POST ... { x: "POST" } $ git push -f origin master ... { _: ['push', 'origin', 'master'], f: true }