Also, I tried your suggested change to apply basePath to everything in rmsEslint.baseConfigs, but:

TypeError: 'basePath' in extends is not allowed.

I believe everything in rmsEslint.baseConfigs should respect the top level basePath anyway, since rmsEslint.baseConfigs are added to extends and not merged into the top level config.

Yes, ESLint will always match **/*{js,cjs,mjs} but will do nothing as no rule is active (this is why I wrote "effectively").
I created a stackblitz which only sets semi for files in src (instead of using extends).
When running eslint . in the terminal, it does not report the missing semicolon in the root file eslint.config.js but only for src/file.js.

First, thank you for the level effort you're putting into answering this.

I checked out your stackblitz and it does work as you described, but only with that same globalIgnores(['**', '!src/**']). I'm trying to avoid the need to effectively maintain included paths in 2 places. For example, if someone added an additional config with a basePath other than src, they'd have to remember to also update the global ignores (otherwise the new ruleset will just silently not apply).

If that's by design, then I can of course accept that, but I thought I must be doing something wrong.

FWIW, as an end user, I find it surprising and unintuitive that eslint makes assumptions about what files to match when I'm providing explicit configuration, but I recognize I don't know all the context and history behind that design.

Actually, I think I may be mistaken. I will double check my setup

Ok @DMartens, I did some additional testing and found that your example does demonstrate that there are no effective rules for the default matches (even without the global ignore).

However, this didn't align with what I observed in my project, so I did some digging and found that my build process was including some // eslint-disable-next-line comments in bundled output. When I run eslint, it processes the bundle and produces an error when it doesn't recognize a rule name.

So, as you said, eslint isn't applying any rules to the default matched files, but is still scanning them and can produce errors in some scenarios.

Scrubbing the eslint comments from my bundle resolves the issue for me, but I don't feel it should be necessary and have concerns about how the unnecessary file reading and processing could impact performance.