fix: type compatibility issue between JSON v2 and ESLint v9

[lumirlumir]

Prerequisites checklist

• I have read the contributing guidelines.

AI acknowledgment

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

What is the purpose of this pull request?

This PR fixes an issue where JSON v2 and ESLint v9 are not type-compatible, as mentioned in #213.

What changes did you make? (Give an overview)

This PR follows the same strategy determined in eslint/markdown#648. That said, a few parts differ from the Markdown implementation, as follows:

1. For JSON, the type compatibility range is 9.15.0 or above, not 9.39.0. This is because the Markdown plugin has a processor, and the blocker for compatibility with lower ESLint v9 versions was that processor. Since CSS does not have a processor configured, broader type compatibility can be achieved.
2. As the type compatibility range is now 9.15.0 or above, I intentionally didn’t mention in README.md that type compatibility is ensured for v9.15.0 or above, since the current type compatibility range is the same as the one we already support.

Related Issues

Refs: eslint/markdown#648, eslint/css#473
Fixes: #213

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

N/A

[lumirlumir]

Unlike the CSS implementation, if we don’t type-cast the return type with JSONRuleVisitor, a portable type error occurs:

The inferred type of 'create' cannot be named without a reference to 'MemberNode' from '../../node_modules/@humanwhocodes/momoa/dist/typedefs.js'. This is likely not portable. A type annotation is necessary.

This was also why only the JSON plugin used the following snippet:

const rule = { /* ... */ };

export default rule;

Instead of:

export default { /* ... */ };

---

I’ve tried to find an easy way to resolve it, but I couldn’t find one we could handle on our own.

I think this issue lies with @humanwhocodes/momoa, since the package still uses a dual CJS/ESM setup and type resolution seems to have broken at some point.

Sending a PR to @humanwhocodes/momoa to make it ESM-only may resolve the type issue, since the portable error seems to come from typedefs.ts not being exported directly from the main entry point ./dist/momoa.js, but instead being exported indirectly.

[fasttime]

I'm not sure how to export dist/typedefs.ts directly from dist/momoa.js. Do you have an idea?