Watch mode exits after first run when using near-operation-file

[mvestergaard]

Describe the bug

When using the near-operation-file preset watch mode exits right after the first iteration.

To Reproduce
Steps to reproduce the behavior:
Run gql-gen with near-operation-file configured

1. My GraphQL schema:

# Schema is huge. If you can't reproduce, I'll try to find the minimal reproduction setup

2. My GraphQL operations:

# Same as above

3. My codegen.yml config file:

schema: ./packages/app/src/graphql/schema/schema.graphql
overwrite: true
documents:
  - ./packages/app/src/**/*.fragment.ts
  - ./packages/app/src/**/*.query.ts
  - ./packages/app/src/**/*.mutation.ts
generates:
  ./packages/app/src/graphql/schema/index.ts:
    plugins:
      - add: '/* eslint-disable */'
      - typescript
    config:
      scalars:
        Date: Date
        DateTime: Date
        DateTimeOffset: Date
        Guid: string
        Decimal: number
        Seconds: number
        Milliseconds: number
  ./packages/app/src/graphql/schema/introspection.ts:
    plugins:
      - add: '/* eslint-disable */'
      - fragment-matcher
  ./packages/app/src:
    preset: near-operation-file
    presetConfig:
      extension: .generated.tsx
      baseTypesPath: graphql/schema
    plugins:
      - add: '/* eslint-disable */'
      - typescript-operations
      - typescript-react-apollo
    config:
      withHOC: false
      withComponent: false
      withHooks: true

Expected behavior

Watch mode should keep running

Environment:

• OS: Windows 10
• @graphql-codegen/1.3.1:
• NodeJS: 12.3.1

Additional context

Other issues with near-operation-file

• Output is quite spammy. As also seen above. Each generated file produces a √ Parse configuration line
• While running, a weird warning appears (i think it comes from prettier, see screenshot below)
• Execution is quite slow compared to generating a single file. At least 300% slower.
• When referencing fragments, alot of unused imports are added to the generated files (i think this has been reported already)

[mvestergaard]

The weird prettier error should be fixed by #2071

[mvestergaard]

@dotansimha I think most of this is resolved, but are you still working out some kinks with near-operation-file? I noticed an issue where the base types file isn't always referenced in mutations and queries, when it should.
If you're not aware of that issue, I can create a new issue for it, and try to provide some minimal reproduction steps.

[mvestergaard]

The issue I'm seeing somehow relates to this bit of code: https://github.com/dotansimha/graphql-code-generator/blob/master/packages/presets/near-operation-file/src/index.ts#L161
I'm wondering whether it may not be easier to just always reference the base types file, and not try to be smart about it. Are there ever cases where a file doesn't need it?

[dotansimha]

Fixed in 1.4.0 🎉