Bug: * is treated as non-universal pattern

[mdjermanovic]

Environment

Node version: v20.12.0
npm version: 10.5.0
Local ESLint version: v9.4.0
Global ESLint version: no
Operating System: windows

What parser are you using?

Default (Espree)

What did you do?

Configuration

export default [
  {
    // configuration for files in the root, typically config files that run in Node.js
    files: ['*'],
    languageOptions: {
      globals: {
        process: 'readonly',
      },
    },
    rules: {
      'no-undef': 2,
    },
  },
];

process.exit(1);

What did you expect to happen?

No errors when running eslint .

What actually happened?

C:\projects\tmp\tmp\.gitignore
  1:1  error  'node_modules' is not defined  no-undef

C:\projects\tmp\tmp\package-lock.json
  2:9  error  Parsing error: Unexpected token :

C:\projects\tmp\tmp\package.json
  2:9  error  Parsing error: Unexpected token :

Link to Minimal Reproducible Example

https://stackblitz.com/edit/stackblitz-starters-5p7i7w?file=eslint.config.js

Participation

• I am willing to submit a pull request for this issue.

Additional comments

Patterns that end with /* are considered non-universal - they don't cause any matching files to be linted. Shouldn't the same apply to lone *?

The same could be argued for **, though maybe it makes sense to leave it as-is, as a special feature of ** (otherwise, it would be the same as **/*).

[nzakas]

Patterns that end with /* are considered non-universal - they don't cause any matching files to be linted. Shouldn't the same apply to lone *?

I agree. Should this be an issue in the rewrite repo?

And just a procedural note: when you open a new issue, it's best to either leave it in "Needs Triage" or move to "Ready for Dev Team" so it's easy to find in the triage board. I tend to lose new issues if they're not in one of those two spots. When something is moved to "Feedback Needed", it should include a ping of @eslint/eslint-team.

[mdjermanovic]

Should this be an issue in the rewrite repo?

The fix would be in the rewrite repo (I'll submit a PR when the issue is accepted), but I think it's better to track issues like this here to make sure we update the dependency (and possibly add tests) before closing the issue.

[nzakas]

Fair enough. We should definitely fix this.