-
Notifications
You must be signed in to change notification settings - Fork 357
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
Unmaintained dependency go-flags #1807
Comments
Feel free to submit a PR if you're interested in contributing this. Otherwise, I don't think we need an open issue here, since "not maintained" is just a negative way to frame "done." If there are maintenance issues going unsolved that affect TFLint then it becomes an issue. |
Not to say this might not change, but it'll likely be for user-facing motivations like subcommands versus an internal refactor because a module isn't getting any more updates. |
Ok thank you! Just wanted to gauge if such a PR would be welcome.
In this case, go-flags actually has open bugs and one issue to update a dependency past CVE-affected versions. |
Fair enough, does the CVE apply to TFLint's usage? If so we should retitle this issue around that and fork/vendor/fix immediately, regardless of refactoring plans. |
At a glance, I don't think it affects tflint; probably just a good idea to move away before other CLI-related work happens. |
(This isn't really a feature proposal per se, apologies if this is the wrong format!)
Introduction
It appears that the go-flags project is no longer maintained. It would be nice to remove the dependency on go-flags.
Proposal
The current option parsing is probably simple enough to just use the standard library
flag
package (though the parsing might look different with #1618).The text was updated successfully, but these errors were encountered: