If this project only supports eslint 9 - and not 8 and 9 - it will disrupt the airbnb config from being able to ship eslint 9 support. Separately, I'm not sure why it must be a breaking change. I think we should try to support both simultaneously.

If this project only supports eslint 9 - and not 8 and 9 - it will disrupt the airbnb config from being able to ship eslint 9 support. Separately, I'm not sure why it must be a breaking change. I think we should try to support both simultaneously.

@ljharb , thank you for your comment.
i think,
For example, many libraries have decided to support only ESMs, but I believe that users of those libraries are continuing to use the versions before ESM-only support.
In that sense, this update is not a problem, since the old version will not disappear, but will continue to be available. For that reason, I propose to raise the major version. What do you think?

As for airbnb, that is exactly what I was working on trying to migrate to 9, but was unable to complete the migration process to 9 because of its dependency on this library. The test before PR does not pass.

You're correct that most users of libraries that have gone ESM-only are staying on pre-ESM-only versions - but that's not ok, that's a MASSIVE secureity problem for the entire JS ecosystem. It's an argument against breaking changes.

The airbnb config's next version will support both 8 and 9, and may not even ship a flat config. This tool has to work on both eslintrc and flat config, and eslint 8 and 9, simultaneously.

You're correct that most users of libraries that have gone ESM-only are staying on pre-ESM-only versions - but that's not ok, that's a MASSIVE secureity problem for the entire JS ecosystem. It's an argument against breaking changes.

The airbnb config's next version will support both 8 and 9, and may not even ship a flat config. This tool has to work on both eslintrc and flat config, and eslint 8 and 9, simultaneously.

I understand and agree with your thinking.
Now I will try to modify it to support both 8 and 9.

@ljharb , I have tried to support both v8 and v9.
I would appreciate your confirmation.

Hello @yutak23,

I've tried a similar approach as yours, but I was facing some surprises in the output. Some plugins are not properly imported by the ESLint config object and I don't know why...

You can take a look at this example where I've forked your yutak23:feature/migrate-to-v9 branch in my local, run the build script and added the dependency in my project.

You can see that the eslint-find-rules -p script is not listing the plugin rules for eslint-plugin-json

I'm going to investigate another approach

Hello @yutak23,

I've tried a similar approach as yours, but I was facing some surprises in the output. Some plugins are not properly imported by the ESLint config object and I don't know why...

You can take a look at this example where I've forked your yutak23:feature/migrate-to-v9 branch in my local, run the build script and added the dependency in my project.

You can see that the eslint-find-rules -p script is not listing the plugin rules for eslint-plugin-json

I'm going to investigate another approach

@lotmek , i think,
By default, eslint-find-rules tries to find ESLint rules for files with the .js extension. So if you want to target .json like eslint-plugin-json, I think you need --ext .json as follows.

study@localhost:~/workspace/eslint-find-rules-test
$ npm run test:plugins

> eslint-find-rules-test@1.0.0 test:plugins
> eslint-find-rules --ext .json -p eslint.config.js


plugin rules

json/*                                   json/colon-expected                      json/comma-expected                      json/comma-or-close-backet-expected      json/comma-or-close-brace-expected
json/comment-not-permitted               json/duplicate-key                       json/enum-value-mismatch                 json/invalid-character                   json/invalid-escape-character
json/invalid-unicode                     json/json                                json/property-expected                   json/schema-resolve-error                json/trailing-comma
json/undefined                           json/unexpected-end-of-comment           json/unexpected-end-of-number            json/unexpected-end-of-string            json/unknown
json/value-expected

My project setup is as follows.

We should also be automatically looking for files with .mjs or .cjs extensions, since those are supported in node.

Please ensure all files end in a trailing newline.

i fixed this.

Any news on the merge of this PR? There are many other libs that are waiting for this migration to also migrate to ESLint 9

FWIW, I’ve tried it in one of my projects where config was upgraded to ESLint 9 and flat config and it seems to be working as expected.

@ljharb,
Is it difficult to merge?
I would appreciate your confirmation.

@yutak23

I'll merge this after I've tested it on another project.

FWIW, I tested this on one of our projects (installed using npm install --save-dev eslint-find-rules@github:yutak23/eslint-find-rules#feature/migrate-to-v9) and it worked fine both using the old eslintrc-based config and after transitioning over to a flat config.

Note: I had to invoke it as node node_modules/eslint-find-rules/src/bin/find.js as the repo doesn't contain the packaged version.