Mark Banner

It looks like it will work that way, but it the plug-in can also be migrated to support flag configuration better: https://eslint.org/docs/latest/extend/plugin-migration-flat-config (it can also support both new & old).

> in Eslint v9 the work-around of @4a-ge does not work unchanged - the recommended ruleset throws. I used > ... > ```js > export default [ > pluginJs.configs.recommended, >...

> IMHO, I prefer this usage design more. ... > This can avoid the breaking change as well. ESLint is already deprecating the old configuration with v9, therefore I think...

> I made changes to the test setup on the main branch so rebased here and force pushed. Thanks, I took a look and noticed one issue with the tests...

Eventually got back around to this... I've figured out a fix for eslint-plugin-self - found here: https://github.com/not-an-aardvark/eslint-plugin-self/pull/9 We'll see if that gets accepted or not. With that fix, I've now...

> As the rules can be configured with an option (`{"allowComments": true}`): don't we need a [schema](https://eslint.org/docs/latest/extend/custom-rules#options-schemas) entry in the meta property (line 107)? Could you maybe file a separate...

> So IMHO it would be enough to add the schema to this PR as this PR is for eslint v9 and above. I'm trying to limit this PR to...

> > So IMHO it would be enough to add the schema to this PR as this PR is for eslint v9 and above. > > I'm trying to limit...

@azeemba I finally found some time and managed to figure out the test issues. I have focussed on making this able to work with flat config which is available in...

> @Standard8 thanks for getting the flat config working! I wanted to discuss a little bit on the logistics on the next steps. This is going to be a breaking...