-
Notifications
You must be signed in to change notification settings - Fork 10
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
Support a simple way to define exceptions for broad rules #24
Comments
@na-- thanks for sharing this use case. Would it be possible to accomplish this by adding exceptions to |
Yeah, that should also work 🤔 From what I can see, the regular expressions there would have to be based on the whole error message and not just the Go identifiers, so it's a bit hacky and potentially fragile, but probably much less hacky than any other currently existing workarounds 😅 |
Possibly related is that over at #22 (comment), I had proposed using tags embedded in comments as a way of targeting sets of rules in the |
There doesn't seem to be an easy way to specify a broad rule, but add a few exceptions to it. Specifically, I'd like to do the following:
os
package everywhere across k6//nolint:forbidigo
in the single place where we assemble our global state from the OSos
types likeos.Signal
, which are safe to use and are valid return types even when we'd be mocking this global state in our tests.Since Go doesn't support negative lookaheads in regular expressions, I am not sure there is an easy way to currently do this?
One way to solve this would be to be able to add a list (or even another regex) for every rule, for defining exceptions to the rule.
Another way would be to specify that only matching a specific group in the regexp constitutes a linter error. Then we'd be able to use "The Greatest Regex Trick Ever" to define rule exceptions 😅
The text was updated successfully, but these errors were encountered: