Add a negate flag

[petemounce]

I would like to add a rule that fails when a regex is not matched, for example a VERSION file containing a v1.0.0 and a pattern like ^v (because a v prefix on a semver is not valid).

[petemounce]

---
# https://semver.org/#is-v123-a-semantic-version
- name: VERSION files must contain semver.
  # LOLWAT? https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string
  pattern: '^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$'
  hint: "https://semver.org/#is-v123-a-semantic-version"
  filePattern: '.*VERSION'

- name: VERSION file contents must not be prefixed with a v
  pattern: '^v'
  hint: "https://semver.org/#is-v123-a-semantic-version"
  filePattern: '.*VERSION'

cmd/VERSION:

v0.1.1

I want that file to fail both rules, not just the 2nd one.

[petemounce]

(and the LOLWAT refers to the regex itself ;) )

[codingjoe]

Hi @petemounce thanks for reaching out. I see your point, how this might come in handy. However, I am not 100% sure on how to integrate this, since we currently work with matches, that have line numbers and snippets, that are being displayed. Inverse matches would mean we only had file names.

Anyhow, I still think it's possible to come up with a good solution. How about you propose a solution. Preferably as a pull-request and I will gladly review and release it.

Best
-Joe

[viktorkertesz]

Hi @petemounce ,
did you try this? (I know it doesn't cover everything, just to get a hang of it)

^(?!\d+\.\d+\.\d+).*$

This won't match the correct versioning string but will trigger everything else.

[mroy-seedbox]

We have a similar challenge on our side. Here is the generalized idea:

• We know the way something should look.
• But it is very hard to describe the way it should not look (and there are possibly an infinite number of possibilities).

Simple/silly example:

• We only want to accept the string ABC if it is immediately followed by either DEF or 123.
• The regex to find ABC is simple, but then it is much more challenging to say "trigger if there is anything else than DEF or 123 afterwards" (maybe not for regex gurus, but those are rare, and the resulting regexes are hard for everyone else to understand & maintain).

What I would propose:

• We keep the current concept of pattern matching to find rows in a file.
• But then we add a new concept/parameter of mustMatch, which would be a positive regex of how the match should look, rather than trying to do it all via a negative/exclusion regex of what something bad looks like.
• pattern would continue to match on rows, and extract the corresponding substring(s).
• mustMatch would then have to find an exact match (in each substring), or the rule would be triggered (for each substring).
• If mustMatch matches, the rule is not triggered.

So the solution to the above would become:

pattern: 'ABC.*' # or maybe 'ABC.{3}'
mustMatch: 'ABC((DEF)|(123))'

And @petemounce, the solution for you could probably look something like this (although I'm probably missing a lot of details):

pattern: '[^\d]\d+\.\d+\.\d+[^\d]'
mustMatch: '[^v]\d+\.\d+\.\d+' # or maybe '"\d+\.\d+\.\d+"'

So much simpler. 💙

@petemounce, @codingjoe: What do you think?

[codingjoe]

Hm… that is an interesting idea. I like the concept of either looking for something that shouldn't be there, or should. I'd love to see this included in a new version. Heck, I'd actually love to implement path to test functions written in Python, like test_func: "package.module:function" and that function gets called with a file's contents.

I believe it's time for a new major release, with some exciting new features and maybe some breaking changes. If anyone is interested in contributing, please let me know.

[mroy-seedbox]

Quick idea: reLint could look for a file called .relint.py in the project root (just like it currently looks for .relint.yml), and source the python module/functions from there. So if we configure test_func: some_function, then it would simply call the some_function function from .relint.py. This also leaves room for a more advanced implementation via package.module:function in the future (although .relint.py could easily integrate with any other package or module, and serve as an interface/facade for reLint).

The functions should probably have a signature along the line of (rule, file, match), where:

• rule is the full corresponding object defined in .relint.yml (with name, pattern, etc.)
• file is the path of the file currently being linted.
  • This could be used to read the file as a string, if necessary.
• match is an individual match for the rule's pattern (if pattern is used in combination with test_func).
  • The function should be called once for each match (or called only once if the rule has no pattern, with none as the match).
  • Or maybe the function signature could just be (rule, file) if it expects to be used without a pattern. And if a function could be usable for both cases (with or without a pattern), it's signature could be (rule, file, match=none).

Related:

• Enhancement: programmatic hook, or structured output, for downstream CLI tools #108

Open question: what kind of return value would reLint expect? 🤔 Returning an object would probably offer the most flexibility, because then new key-values could easily be added in the future (since we cannot possibly predict every need).

[codingjoe]

Hi there 👋,

Yes, the idea of adding declarative tests has been floating around for a while. I am not opposed to the idea. However, I feature can coexist on their own. Don't hesitate to open a separate issue or discussion for such a feature.

Cheers!
Joe