Support eslint's new flat config

[cprussin]

Fixes #166 .

Note I also had to change the strategy for running integration tests is this PR. Prior to this PR, integration tests ran in a child process where the cwd was the root of the integration tests, and jest projects were used to select individual integration test directories. However, eslint will look for the flat config starting in the process cwd, so with that strategy the flat config would have to be placed in a common path to all integration tests, and thus the integration test runs would always detect that they're running in flat config mode.

As of this PR, the integration tests run with a child process where the cwd is the individual integration test fixture path as well. Practically, this required updating some snapshots and moving some .eslintignore entries into the test fixture folders.

[cprussin]

cc @SimenB @ljharb

[ljharb]

This seems worth splitting into two PRs - one changing the way the tests work, and another after that lands that adds support for eslint's flat config?

[cprussin]

I could @ljharb but it seems like unnecessary churn, especially if the two PRs will land one after another and if the only motivation to do the one is in order to introduce the other.

[ljharb]

The point would be to a) reduce the git diff size, and b) prove that the test refactors pass without changing the production code, both of which reduce the risk of any change.

[cprussin]

The point would be to a) reduce the git diff size, and b) prove that the test refactors pass without changing the production code, both of which reduce the risk of any change.

Fair enough, I'll split it up tomorrow and will investigate the failing tests tomorrow. New PRs inbound soon.

[ljharb]

Let's try to send just one new PR, and update this one to be one of the two parts :-) Thanks!

[cprussin]

@ljharb I'm going to put this on hold for a bit for two reasons:

1. Pending the reply in Change Request: expose shouldUseFlatConfig (or a wrapper API that selects between the two formats automatically) eslint/eslint#17129, that could significantly simplify things -- ideally the eslint folks will support exposing an API that switches between ESLint and FlatESLint automatically and that would cut down on much of the change in this PR.

2. I'm also fairly sure the CLIEngine code is not necessary any more as jest-runner-eslint no longer supports older versions of eslint where that would have been applicable. I'll double check that and will submit a separate PR to strip that out, which will further simplify this.

If both of those last 2 work out, and once #177 gets merged, this PR will turn into effectively just a one-line change of an import path

I'll keep the PR open until I wrap those other changes up and then will rebase accordingly and ping you when I think it's ready to merge.

[cprussin]

@ljharb I think this PR is good to merge now if you'd like. I'm guessing it will take the eslint folks some time to get back to me on eslint/eslint#17129 and then I'll need to implement and PR and merge whenever they suggest. I'm happy to wait on that and then update this PR once something lands, or also happy to get this merged in and then go back and put in a follow-up PR whenever the eslint side moves forward.

[cprussin]

@ljharb OK I think that should do it, I added an integration test to be sure we don't try to load the config using the flat format on eslint versions that don't support it. Let me know if there's anything else you'd suggest.

Thanks for the reviews & help getting these merged!

[ljharb]

this should be rebased, but otherwise lgtm. not going to merge without other reviews tho

[cprussin]

rebased, thanks @ljharb

[cprussin]

addressed your comments, thanks @SimenB

[cprussin]

FYI that I just added a change to cache the ESLintConstructor value as I noticed the performance with this PR was quite poor due to traversing the filesystem to find the eslint.config.js file on each lint run prior to adding the caching.

[cprussin]

@ljharb @SimenB any other changes ya'll would like to see here? did you want to ice this pending any outcome of eslint/eslint#17129 or were you guys cool with merging and I can do a follow up if/when that ticket moves along?

[cprussin]

@ljharb @SimenB friendly nudge here -- anything else ya'll wanted to see here that I can polish off?

[cprussin]

@ljharb @SimenB eslint v8.41.0 has been released, including my change to expose shouldUseFlatConfig. I've rebased this PR on top of main, reverted changes to package.json and yarn.lock, and made the change we discussed. I've also upgraded eslint in the yarn.lock to v8.41.0 so that we're actually testing on the flat config code in CI.

I think the only deficiency in this PR at this point is that I didn't add any CI to test with eslint versions between v8.0.0 - v8.40.0. I don't think that's necessary and it felt like overkill to me, but I'd be happy to go back and add it if ya'll feel it's important.

Other than that, I think it's good to ship. Thanks again for the patience and help folks.

[SimenB]

A test run for 8.40 could be nice, but if it proves hard I don't think it's a blocker 🙂 At least as long as we still test v7 I think it's highly unlikely we'll break anything

[cprussin]

A test run for 8.40 could be nice, but if it proves hard I don't think it's a blocker slightly_smiling_face At least as long as we still test v7 I think it's highly unlikely we'll break anything

No problem, added 8.40 to the test matrix. It might prove to be overkill and wasted github action time but it's easy to strip out from the matrix config down the line.

[cprussin]

@SimenB @ljharb either of you cool with merging this? I'd love to get it upstreamed and be off my fork!

[SimenB]

Thanks, and sorry for the delay!

Currently afk, but I can release this tonight or tomorrow morning (CEST), unless @ljharb gets to it 🙂

[cprussin]

No worries at all, thanks for all the help getting this over the finish line!

[SimenB]

https://github.com/jest-community/jest-runner-eslint/releases/tag/v2.1.0