Bug: Parse error with empty files

[HolgerJeromin]

Environment

ESLint version: v9.39.4
@eslint/json version: 2.0.0
Node version: v24.16.0
Operating System: Windows 11

Which language are you using?

json

What did you do?

Configuration

import { defineConfig } from 'eslint/config';
import json from '@eslint/json';
export default defineConfig([
    {
        files: ['**/*.json'],
        ignores: ['**/tsconfig*.json', '**/package-lock.json', '**/.vscode/**'],
        plugins: { json },
        language: 'json/json',
        extends: ['json/recommended'],
    },
]);

I have some empty files in my repo with the extension .json.

What did you expect to happen?

A clean understandable error message would be nice.

Even better: an option like allow-empty-files.

What actually happened?

> npx eslint --debug .\emptyFile.json
  eslint:cli CLI args: [ '--debug', '.\\emptyFile.json' ] +0ms
  eslint:cli Using flat config? true +2ms
  eslint:cli Running on files +8ms
  eslint:eslint Using config loader LegacyConfigLoader +0ms
  eslint:eslint Using file patterns: .\emptyFile.json +1ms
  eslint:eslint Deleting cache file at C:\git\myProj\.eslintcache +0ms
  eslint:config-loader Calculating config for file C:\git\myProj\emptyFile.json +0ms
  eslint:config-loader Searching for eslint.config.js +0ms
  eslint:config-loader [Legacy]: Calculating config for C:\git\myProj\emptyFile.json +3ms
  eslint:config-loader [Legacy]: Using config file C:\git\myProj\eslint.config.mjs and base path C:\git\myProj +1ms
  eslint:config-loader Calculating config array from config file C:\git\myProj\eslint.config.mjs and base path C:\git\myProj +0ms
  eslint:config-loader Loading config file C:\git\myProj\eslint.config.mjs +2ms
  eslint:config-loader Loading config from C:\git\myProj\eslint.config.mjs +1ms
  eslint:config-loader Config file URL is file:///C:/git/myProj/eslint.config.mjs +0ms
  eslint:config-loader Config file C:\git\myProj\eslint.config.mjs is not empty +51ms
  eslint:eslint 1 file(s) found in 64 ms +64ms
  eslint:eslint Linting in single-thread mode. +1ms
  eslint:config-loader Looking up cached config for C:\git\myProj\emptyFile.json +2ms
  eslint:config-loader [Legacy]: Looking up cached config for C:\git\myProj +0ms
  eslint:eslint-helpers File "C:\git\myProj\emptyFile.json" read in 5 ms +0ms
  eslint:linter Linting code for C:\git\myProj\emptyFile.json (pass 1) +0ms
  eslint:linter Verify +0ms
  eslint:linter With flat config: C:\git\myProj\emptyFile.json +1ms
  eslint:linter Generating fixed text for C:\git\myProj\emptyFile.json (pass 1) +4ms
  eslint:source-code-fixer Applying fixes +0ms
  eslint:source-code-fixer shouldFix parameter was false, not attempting fixes +0ms
  eslint:eslint-helpers File "C:\git\myProj\emptyFile.json" linted in 7 ms +9ms

C:\git\myProj\emptyFile.json
  0:0  error  Parsing error: Cannot read properties of undefined

✖ 1 problem (1 error, 0 warnings)

Link to Minimal Reproducible Example

trivial

Participation

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

AI acknowledgment

• I did not use AI to generate this issue report.
• (If the above is not checked) I have reviewed the AI-generated content before submitting.

Additional comments

No response

[DMartens]

Thank you for filing an issue for this.
The error is from the parser we use, so I filed an issue there.
Regarding the proposed option to allow empty files: I do not see a use case for this.
The JSON file should be used somewhere and then the parser will throw an error as an empty file is invalid. Can you please further explain the use case of the option?

[HolgerJeromin]

Regarding the proposed option to allow empty files: I do not see a use case for this.

Yeah, I understand.

Our use case it:
We have some template files we create as a config file for another process. When this is empty the default values are used (and the config rewritten).
But when we have an empty object this json is not valid and start is aborted.
But yes, the flow is fragile.
We now added them into an ignore rule at eslint level.

[lumirlumir]

Okay, a newer version of @humanwhocodes/momoa was released about a week ago, and no one has picked it up in the meantime, so I’ll work on it.

---

I’ve now found that the version bump commit is present in humanwhocodes/momoa@d3fa355, but the release CI failed, so the newer version of @humanwhocodes/momoa hasn’t been released. I’ve opened an issue at humanwhocodes/momoa#235.