Skip to content
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

Disable "--no-(.*)" filter #42

Closed
YHAMSTM opened this issue Jul 3, 2023 · 5 comments
Closed

Disable "--no-(.*)" filter #42

YHAMSTM opened this issue Jul 3, 2023 · 5 comments

Comments

@YHAMSTM
Copy link

YHAMSTM commented Jul 3, 2023

Hello,

I'm opening this PR to know if we can have the ability to disable a part that catches an arg which starts with "no" and transform it into another string with value set to false.
For my current wrapper, I would like to let the string with "no" and value to "true".
I would see for example a new flag when calling minimist to disable transformation these/this transformation(s)

} else if ((/^--no-.+/).test(arg)) {

Best regards,
Yanis

@ljharb
Copy link
Member

ljharb commented Jul 3, 2023

Related to #38.

I'm confused what you're asking for. The --no-x behavior meaning --x=false has been around a long time, and is pretty common in the ecosystem for boolean args. Can you elaborate on the exact arg input you want, and what parsed output you want to see?

@YHAMSTM
Copy link
Author

YHAMSTM commented Jul 4, 2023

Hello,
Yes, I agree with you.
However, for my use case, I'd like to use minimist for user input validation (associated with express validator) in order to have inputs for CLI calls.
CLI in the backend requires to have the exact input associated to it without other interpretation.

I would like to have --no-x resolving to no-x: true instead of x: false

That's why I think it can be good (if you agree) to have an option to enable this transformation or not (by default it can stay true to not have any breaking changes)

@shadowspawn
Copy link
Collaborator

shadowspawn commented Jul 4, 2023

Thanks for the extra detail. I think this is something you can do reasonably easily in user code, and not a common requirement. (I might be proved wrong by up votes though!)

I don't want to add configuration for all the variations of representing the options. For example, yargs-parser has a common heritage with Minimist and supports:

  • strip-aliased
  • strip-dashed
  • camel-case-expansion
  • boolean-negation <-- this is the one that controls what you want
  • negation-prefix

For comparison with another alternative, parseArgs from node:util processes --no-foo as no-foo and has a strict mode. (Minimist does not have a strict mode, although we are thinking about it: #41)

@YHAMSTM
Copy link
Author

YHAMSTM commented Jul 4, 2023

Thanks for your replies and your advice.
Indeed, yargs-parser looks like a perfect fit for my use case.

If its not a feature to be planned, I will close the issue

@YHAMSTM YHAMSTM closed this as not planned Won't fix, can't repro, duplicate, stale Jul 4, 2023
@shadowspawn
Copy link
Collaborator

(Note: I am one of two maintainers and speaking for myself. Second opinion likely. 😄 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants