graphql-eslint icon indicating copy to clipboard operation
graphql-eslint copied to clipboard

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

Open ghmeier opened this issue 2 years ago • 0 comments

Issue workflow progress

Progress of the issue based on the Contributor Workflow

  • [x] 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
  • [x] 3. A local solution has been provided
  • [x] 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: https://github.com/ghmeier/graphql-eslint/pull/1

ghmeier avatar Jul 18 '22 17:07 ghmeier