fix: Ensure globbing doesn't include subdirectories

[nzakas]

Fixes #16260

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

I changed the resolution mechanism for globbing. Previously, we were automatically looking for every glob pattern inside of the cwd, which could result in more files than necessary being linted. Now, we only look at glob patterns relative to the directory passed in on the command line.

Is there anything you'd like reviewers to focus on?

Please take a look at the new shallow-glob fixture to make sure it makes sense. I verified that the test using these files failed prior to this change and passed after this change.

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	8fc387c
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/6318f67e8ce84b0009f6f4b7

[mdjermanovic]

This won't work well when ** (or anything else that isn't a literal directory name) is in the middle of filePattern.

For example:

// eslint.config.js
module.exports = {
    files: ["foo/**/*.md"],
    // ...configuration for .md files
};

Command eslint foo/bar, where foo/bar is an existing directory, would not find .md files in foo/bar directory because patternRelativeToFilePath will be calculated as ..\**\*.md.

[mdjermanovic]

It also doesn't work when the pattern starts with a non-literal (except for the special-cased **).

For example, if the config entry has files: ["{foo,bar}/*.md"], command eslint foo won't find .md files in foo because patternRelativeToFilePath is ..\{foo,bar}\*.md, so the pattern gets filtered out here.

[nzakas]

Hmmm, yeah, this is the trickiest part of all of this. Do you have any suggestions?

[mdjermanovic]

For this step (filtering out patterns that can't match inside the given directory), I think we could use minimatch with partial: true. But then there's the next step where we should adjust the remaining patterns to match only inside the given directory, which seems overly complex.

[mdjermanovic]

Some alternative approaches:

1. Use globby to simply get all files in the directory (if the given directory is foo/bar, pass foo/bar/**) and then filter out those that don't match at least one pattern that doesn't end with a *. I think this solution is the least error-prone.
2. Negative patterns work as logical AND, so it might be possible to get the intersection by appending some form of double negation to the list of patterns.

[nzakas]

Thanks for the suggestions. These were super helpful. I went with a minimatch-based approach that seems to work. I didn't need to use partial: true because we actually do have the full path at that point.

[nzakas]

I can't reproduce the lint error locally, so I have no idea what's going on there.

[nzakas]

Nevermind, I can reproduce it now. Didn't notice there was a separate command for linting docs JavaScript files.

[nzakas]

@mdjermanovic I could use your help figuring out why the linting in the docs directory is broken. I'm a little confused as to why this lint step is separate and where exactly it's reading its config from.

[mdjermanovic]

why this lint step is separate and where exactly it's reading its config from.

It's separate from the main lint because linting docs requires docs/node_modules installed. The reasoning is in this comment:

eslint/Makefile.js

Lines 508 to 518 in 42bfbd7

	/*
	* In order to successfully lint JavaScript files in the `docs` directory, dependencies declared in `docs/package.json`
	* would have to be installed in `docs/node_modules`. In particular, eslint-plugin-node rules examine `docs/node_modules`
	* when analyzing `require()` calls from CJS modules in the `docs` directory. Since our release process does not run `npm install`
	* in the `docs` directory, linting would fail and break the release. Also, working on the main `eslint` package does not require
	* installing dependencies declared in `docs/package.json`, so most contributors will not have `docs/node_modules` locally.
	* Therefore, we add `--ignore-pattern docs` to exclude linting the `docs` directory from this command.
	* There is a separate command `target.lintDocsJS` for linting JavaScript files in the `docs` directory.
	*/
	echo("Validating JavaScript files");
	lastReturn = exec(`${ESLINT}${fix ? "--fix" : ""} . --ignore-pattern docs`);

It uses the same top-level .eslintrc.js/eslint.config.js config file.

The problem will be fixed by #16274

[nzakas]

Oh nice! I'll rebase on top of that.

[mdjermanovic]

I still think we would need { partial: true } for this approach.

Consider the following example.

Config:

{
    files: ["t*/internal-rules/*.js"],
    // ...
}

Command:

eslint tools

The "t*/internal-rules/*.js" pattern from the config should not be filtered out, because it can match something under the tools directory?

Current behavior:

filePath: D:\projects\eslint\tools
fullFilePattern: D:\projects\eslint\t*\internal-rules\*.js
path.dirname(fullFilePattern): D:\projects\eslint\t*\internal-rules
minimatch(filePath, path.dirname(fullFilePattern)): false

I think what we need is:

if (minimatch(filePath, fullFilePattern, { partial: true })) {
    return true;
}

filePath: D:\projects\eslint\tools
fullFilePattern: D:\projects\eslint\t*\internal-rules\*.js
minimatch(filePath, fullFilePattern, { partial: true }): true

[nzakas]

Ah gotcha. I think I misunderstood the purpose of partial: true.

[btmills]

Unfortunately mdjermanovic hasn't been able to follow up on the open discussions. Mitigating that, 1) the suggestions from those discussions look to have been implemented as discussed, and 2) this is use-at-your-own-risk code that's easier to change post-release.