Add --no- prefix support for boolean flag negation#52
Add --no- prefix support for boolean flag negation#52privatenumber merged 1 commit intoprivatenumber:developfrom
Conversation
|
Thanks for this and for the context on the Backstage migration — glad cleye is working well for you. I like the idea of typeFlag({
verbose: Boolean,
}, argv, { booleanNegation: true })When enabled, If that sounds good I can push to this PR with the updated approach. |
|
Love it! Indeed I had the same concern, you can push updates to this PR. Would this manifest as a global option in |
ba876c1 to
e139eb5
Compare
|
Pushed the updated approach to this PR — rebased on For cleye I'll expose it as a global |
e139eb5 to
f462aed
Compare
8c4c3f2 to
3906bdc
Compare
3906bdc to
f0bfb67
Compare
|
🎉 This PR is included in version 4.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 5.0.0-beta.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Hello @privatenumber! 👋
I've been searching for good simple flag parsers with TypeScript support for adoption in the Backstage project, and
cleyecaught my... eye 🤦. We're looking at what a potential migration looks like (backstage/backstage#33061 if you're curious, WIP), and overall it's very smooth.One diff that we spotted was the support for automatic
--no-prefixes for boolean flags. It's not a huge deal and we might also implement our own wrapping and deprecation and get rid of support for it, but I wanted to check in here what your appetite for supporting it natively is.I ended up with the implementation here as a minimal zero-config approach but of course with a bit more opinionation baked in, compared to for example Node.js'
allowNegativeoption forutil.parseArgs. I also tried an implementation incleyedirectly with a preprocessing step, but that got ugly fast.Let me know what you think, happy to try other approaches or skip altogether 🙏