Cached operations are not reset when source files change with eslint-plugin-webpack

[ghmeier]

Issue workflow progress

Progress of the issue based on the Contributor Workflow

• 1. The issue provides a reproduction available on GitHub, Stackblitz or CodeSandbox

Please make sure the graphql-eslint version under package.json matches yours.

• 2. A failing test has been provided
• 3. A local solution has been provided
• 4. A pull request is pending review

---

Describe the bug

When eslint is used to watch changes to files (like via eslint-plugin-webpack, or when using create-react-app), rules that rely on the operationsCache fail to update their status after the source file changes. This specifically affects fragments used in those files. For example, if a file looks like this:

// index.ts
import gql from 'graphql-tag';

const fragment = gql`
	  fragment Test on User {
		  name
	  }
`

const query = gql`
	query LoggedInUser {
		user {
			...Test
		}
	}
	${fragment}
`

The rule will show a require-id-when-available error on the fragment initially, but if the id field is added, the error will persist until the eslint process is restarted.

To Reproduce
Steps to reproduce the behavior:

Here's a codesandbox set up to demonstrate the error: https://codesandbox.io/s/graphql-eslint-issue-6nskdj?file=/src/App.js

Running yarn client will initially show an error, but when that error is fixed, it doesn't go away.

Expected behavior

The rules should handle changes to files during a single eslint process and resolve errors without requiring rerunning.

Environment:

• OS: MacOS / Linux
• @graphql-eslint/eslint-plugin: 3.10.6
• Node.js: 16.13.2 / 18.6.0

Additional context

I've included a PR with a proposed fix for the issue: ghmeier#1

[dylanwulf]

Hello, I would love to see this fixed and I'm happy that someone has created a PR for this already. I noticed that the PR was created on your fork instead of on this repo, maybe it would have a better chance of getting reviewed if the PR were submitted to this repo instead?

[ghmeier]

Great call @dylanwulf, I've added a PR #1207

[dimaMachina]

@ghmeier Thanks for your work, this issue is similar to #593

I see already an issue in your PR:

• you will add schema files to the operations cache also, and we don't want it (or maybe I'm wrong)
• when you remove the operation from the code file -> operation will be still present in the cache
• you marked as there are some tests, but tests are missing

I plan to find a workaround to both problems in schema/operations in the current/next sprint

[ghmeier]

Glad this is a priority in the next sprint. You're welcome to make modifications to my PR to fix those issues. I mostly put it up as a starting point and conversation starter.

you will add schema files to the operations cache also, and we don't want it (or maybe I'm wrong)

Could you point to where you see that? From what I can see, the logic for handling files and adding them to the cache is the same as it is currently.

when you remove the operation from the code file -> operation will be still present in the cache

This is true, but perhaps a separate bug since that also already exists today?

you marked as there are some tests, but tests are missing

I think unit tests would be pretty burdensome to write for this case. I marked that as complete because I outlined a repro case in this PR that fails without the change, but passes with it.

[dimaMachina]

Hi @ghmeier @dylanwulf ! Future release with cache invalidation could be tested in the following alpha version 3.13.0-alpha-20221024000319-1089aa0

[dimaMachina]

released in @graphql-eslint/[email protected]