Unexpected ignore matching: RegEx vs Unix-like expression matching

[ericcornelissen]

I'm using the "ignore" configuration to ignore some dependencies for an npm project and am observing some unexpected behavior. For context, I'm using dirty-waters-action, tracking in ericcornelissen/shescape#1883.

In my latest attempt I used the config:

{
  "ignore": {
    "@types/*": ["source_code"],
    "concat-map@0.0.1": ["source_code"],
    "file-entry-cache@8.0.0": ["source_code"]
  }
}

and it resulted in packages being ignored according to the copy-pasted table below (at least I think the "Notes > Other info" section from the report shows the ignored dependencies?). I don't understand why, for example, @typescript-eslint/scope-manager@8.31.1 is being ignored because it doesn't match any of the three patterns I listed.

(It would match @types*, that's why I included the /. However, when I was using @types* it did not ignore anything for me, except for the last three in the table below).

index	package_name	github_url	parent
1	@types/debug@4.1.12	Could not find repo from package registry	[]
2	@types/estree@1.0.7	Could not find repo from package registry	['rollup@4.39.0']
3	@types/http-cache-semantics@4.0.4	Could not find repo from package registry	[]
4	@types/istanbul-lib-coverage@2.0.6	Could not find repo from package registry	[]
5	@types/json-schema@7.0.15	Could not find repo from package registry	[]
6	@types/katex@0.16.7	Could not find repo from package registry	[]
7	@types/mdast@4.0.4	Could not find repo from package registry	[]
8	@types/ms@0.7.34	Could not find repo from package registry	[]
9	@types/mute-stream@0.0.4	Could not find repo from package registry	[]
10	@types/node@22.7.4	Could not find repo from package registry	[]
11	@types/normalize-package-data@2.4.4	Could not find repo from package registry	[]
12	@types/unist@2.0.11	Could not find repo from package registry	[]
13	@types/unist@3.0.3	Could not find repo from package registry	[]
14	@types/wrap-ansi@3.0.0	Could not find repo from package registry	[]
15	@typescript-eslint/scope-manager@8.31.1	Could not find repo from package registry	['@typescript-eslint/utils@8.31.1']
16	@typescript-eslint/types@8.31.1	Could not find repo from package registry	['@typescript-eslint/typescript-estree@8.31.1', '@typescript-eslint/visitor-keys@8.31.1', '@typescript-eslint/scope-manager@8.31.1', '@typescript-eslint/utils@8.31.1']
17	@typescript-eslint/typescript-estree@8.31.1	Could not find repo from package registry	['@typescript-eslint/utils@8.31.1']
18	@typescript-eslint/utils@8.31.1	Could not find repo from package registry	[]
19	@typescript-eslint/visitor-keys@8.31.1	Could not find repo from package registry	['@typescript-eslint/typescript-estree@8.31.1', '@typescript-eslint/scope-manager@8.31.1']
20	concat-map@0.0.1	Could not find repo from package registry	['brace-expansion@1.1.11']
21	file-entry-cache@8.0.0	Could not find repo from package registry	[]
22	pp-test-kit@0.5.1	git+https://gitlab.com/ericcornelissen/pp-test-kit.git	[]

[randomicecube]

@ericcornelissen you raise a valid concern, which is that Python's (and probably others) ReGex matches aren't the same as, for example, Unix ones (see screenshots below)

I'm not quite sure how to approach this: I assume most people would be expecting the Unix format, but still

[randomicecube]

For reference, if following Unix matching format, this would be the alternative: https://docs.python.org/3/library/fnmatch.html

[ericcornelissen]

I see. I think regular expressions are fine. I just assumed it was using Unix matchers because the example, @types*, does not make much intuitive sense as a regular expression (why would I want to match @type followed by zero or more s?).

I'm not sure if Unix matchers(/globs) are better because those were designed for file system hierarchies and package names don't necessarily align with that. On the other, something like maven packages heavily rely on ., so regular expressions may behave unexpectedly in that setting...

[randomicecube]

I agree, I think the examples should have been better, I have fixed them now.

I'll still leave this issue open as a discussion one, for more people to chime in on whether Unix-like or "normal" matchers would make more sense.

[ericcornelissen]

Converted the pattern to a regexp and now it works as expected, thanks!

One final comment/note on this topic from my side, I would expect these regular expression to match the whole package name (in regular expression terms, have a start and end anchor as ^...$ where ... is what I put in my config) so that @types.* matches @types/foobar but not foobar@types. You might already do this, I haven't tested it.