Compile allow and deny list as globs to allow wildcards

[philwitty]

• as the glob special characters are not valid package names this should not cause compile errors for any matches of existing modules

[dixonwille]

I am contemplating if this matters. But there was a performance benefit to only allowing prefixing instead of globs. Globs require to go through the array from the start to the end (the sorting that was done is no longer needed and maybe not expected).

Doing string comparison in comparison is cheaper and I can do a binary search (sort.Search) requiring potentially even fewer comparisons against what could be pretty lengthy slice (think mono repository with many packages).

There are significantly fewer files than imports so was willing to take the hit of globs there. Plus, globing against a well structured package (one controlled by the maintainers of the linter configuration) makes logical sense. But not every go project is built the same. So globing at package level seemed a bit like false security (don't include any package with the name test?). Prefixing made the most sense as I may not trust X organization and I can just exclude it with a prefix...

[dixonwille]

File may not be json.

[dixonwille]

This modifies the input slice which can be unexpected behavior to the consumer (if there are any). That is why I had it copied to an internal slice before sort.

[philwitty]

I am contemplating if this matters. But there was a performance benefit to only allowing prefixing instead of globs. Globs require to go through the array from the start to the end (the sorting that was done is no longer needed and maybe not expected).

Doing string comparison in comparison is cheaper and I can do a binary search (sort.Search) requiring potentially even fewer comparisons against what could be pretty lengthy slice (think mono repository with many packages).

There are significantly fewer files than imports so was willing to take the hit of globs there. Plus, globing against a well structured package (one controlled by the maintainers of the linter configuration) makes logical sense. But not every go project is built the same. So globing at package level seemed a bit like false security (don't include any package with the name test?). Prefixing made the most sense as I may not trust X organization and I can just exclude it with a prefix...

Really good points, we certainly could optimise the globbing if performance is an issue (i.e. using a custom globber which given the well defined package names that sounds reasonable), as there isn't any cleverness in the current matching this shouldn't be a noticeable performance decrease I think.

Not sure I understand your second point about the use, I should have made my use case clear in the PR, we wanted to have a shared linter config across many repos but ensure none of them were using any our-organisation/{repo}/test/ packages in non test code

[ezk84]

This makes sense for a use case I have, where I want to enforce dependency rules in a layered application implementing Clean Architecture:

contexts/
   context-a/
     internal/
       adapters/
       app/
       domain/
   context-b/
     internal/
       adapters/
       app/
       domain/

One such rule might say:

• inside each context, app must not depend on adapters or any subpackage

prefix-only matching would force us to update the config for any new context we add to the application, whereas with package globs this would be simple:

prevent_app_deps_adapters:
  files: 
    - <my-repo>/contexts/**/internal/app/**/*.go
  deny:
    - pkg: <my-repo>/contexts/**/internal/adapters
      desc: Application layer can't depend on adapters