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.