Currently when we get diagnostics we aren't showing it at the correct line, this because these properties don't exist

Currently we send a message to the user about them missing a fragment import, however we could add suggested code fixes so it gets automatically imported

Currently, there are no errors thrown / displayed if you have unused variables in a named query. However, this breaks the codegen, so it would be nice if it would show red lines for unused variables the way that the GraphQL VSCode plugin did.

Thanks!

1. The fragment sometimes doesn't get picked up. Restarting the TS server fixes it.
2. Once it's fixed, I can't right click a fragment to jump to it (the VSCode extension allows this, it's nice). I can open a separate issue here if you want.

When we don't define a variable to catch the tagged-template we get an off by one

example

gql`
  query Pok($limit: Int!) {
    pokemons(limit: $limit) {
      id
      classification
    }
  }

`

Would be awesome if this would autocomplete from the schema and base GQL types, when typing the type for an variable name

We need to figure out whether there are better ways to convey errors/... to our users as currently this involves enabling TS Server Logging which isn't the best DX and the setup error could be minimal

Currently when we have a FragmentDefinition in the document it will suggest spreading it anywhere, we only want this to happen when we are asking for suggestions on the correct type.

I accidentally did this:

query Artist($slug: String!) {
  artist($slug: $slug) # notice the incorrect dollar sign $slug on the left

  # it should be artist(slug: $slug)
}

There's an unnecessary $ in the variable name. I'd expect this to turn red, as the $slug variable name doesn't exist for artist(slug)

Since switching to pnpm breakpoints have stopped working when running in example/, I would love to take a look here. We also might need to introduce a build:watch command that produces a non-minified bundled piece of code to add breakpoints to.

Add optional-diagnostic where we look at the imports of a file and warn when the file has exported fragments that aren't imported/used in the file.

example Todo.ts

export const TodoFields = gql`
  fragment todoFields on Todo { name }
`

export default function Todos(props) {
  return <p>{props.name}</p>
}

example Todos.ts

// Would warn if this isn't imported
import Todo, { TodoFields } from './Todo'

export const TodosQuery = gql`
  query todos {
    todos {
      id
      ...todoFields
    }
  }

  ${TodoFields}
`

The suggestions it's giving here are the names of other mutations.

I copy pasted the following

export const PokemonFields = gql`
  fragment pokemonFields on Pokemon {
    id
    name
    attacks {
      fast {
        damage
        name
      }
    }
  }
` as typeof import('./Pokemon.generated').PokemonFieldsFragmentDoc;

to create a second query

export const WeaknessFields = gql`
  fragment weakFields on Pokemon {
    weaknesses
  }
` as typeof import('./Pokemon.generated').PokemonFieldsFragmentDoc;

and rather than renaming the latter to leverage WeaknessFieldsFragmentDoc it renamed the first which is very incorrect. This most likely happens because we just do a substring replace which leverages the index of the first occurrence.

A potential solution here would be to perform the replace on a substring of the source-text that starts at node.getStart()

I'm trying to type ... but it appears to automatically insert a field when I type a second period.

Is this because it doesn't find a matching fragment?

Currently we don't have tests yet but we should find a way to mock all the behavior and test whether we show the correct things, ...

Currently every .generated file contains the metadata from typescript, we probably want to hoist this to a top-level __generated__ folder so we reduce the file-size for the typed-document nodes.

Currently we always write to the source-file which could get annoying for our user when they are editing the file because as soon as the diagnostics are cleared we'll snapshot and edit that snapshot so further edits are ignored until they reload the file from disk.

There are several options here but the easiest to me feels like finding a way to see whether we are looking at a saved version and if so then only write to it as TS will mark the file as dirty and reload it when there are no local pending edits. This most likely could also be done by moving the generation out of getSemanticDiagnostics and using some watch on the project and edit that way.

Another option would be to find a way to edit the local-edit cache of the user but this feels a lot more complex.

i.e. when using a components/index.ts that exports all components we will have a ton of warnings. The solution might be looking at the exports from here and digging deeper when we see a re-export or several of those.

We need to find a way how to handle multiple fragments in a document i.e.

fragment x on Y { id }
fragment y on X { id }

This might lead to us stubbing in the wrong export-name for the document, we should investigate whether GQL-code-generator can handle this and whether we provide the correct export name.

Add test for case like this

gql`
  ${Fragment} --> contains error

  query x {
    someUnknownField --> is errored field
  }
`;

We should see an annotation on ${Fragment} about the underlying error and one on someUnknownField the solution for this is part of #73 and #78

Currently if we have leading fragment references the quick-info cursor-position will be erroneous

When hovering the first character of a field the hover-information isn't working correctly

I have been dogfooding this lib quite thoroughly as of late and it seems like we cause some major slowdowns due to how often TS calls the diagnostics hook. We need to perform some caching where the key could be a combo of the schema and the tagged template.

When we have a document like

const x = gql `query { todos { id } }`

const y = gql `query { authors { id } }`

The TypeScript LSP will start missbehaving as we are performing two separate updates rather than one large one.

Some API's protect their introspection behind an Authorization header, we want to support these however it would be quite... odd to allow folks to pass this in through .json as they wouldn't be able to use environment variables/...

In graphql-code-generator this is already supported through their js-config https://t.co/4WeKtQzeww

• automatically generated TypedDocumentNode for found queries and fragments
• add diagnostic for untyped gql invocations
• add code-hint to add the type to untyped gql invocations

When we have a nested-fragment that i.e. spreads an unknown fragment or has an unknown field we potentially surface this error as part of the main operation

The following

export const x = gql`
  fragment someFields on Smth {
     someUnknownField
  }
`

const query = gql`
  query x { ...someFields }
  ${x}
`

Will surface the unknown field both as part of query as well as of x, while this is correct it gives a lot of noise.

Currently if we have duplicated fragment use then we report an error, this could be because a component is used multiple times in different sub-components leading to a fragment being used multiple times. We should give people the option to filter out these warnings.

When we are using the auto-complete we should not display id when it's already used, neither should we propose a fragment-spread when it has already been spread.

fetch might prove slightly harder due to the sync nature of these plugins

I updated the vs code settings as recommended and this is my tsconfig. I don't see any syntax highlighting or autocomplete. How can i debug this?

{
"compilerOptions": 
{
    "strict": true,
    "target": "es5",
    "baseUrl": "src",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "checkJs": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true,
    "noEmit": true,
    "noUnusedLocals": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": false,
    "plugins": [
      {
        "name": "@0no-co/graphqlsp",
        "schema": "http://127.0.0.1:8000/graphql/",
        "disableTypegen": true,
        "templateIsCallExpression": true,
        "template": "graphql"
      }
    ]
  },
  "include": ["src", "eslint-plugin-canal", "*.js", "next-env.d.ts", "codegen.ts"],
  "exclude": ["node_modules"]
}

When we update the name of an operation that already had a generated typedDocumentNode it will append the new asType rather than replacing the old one.

We can't generate TypedDocumentNodes for operations without an operationName, hence we need to warn our users for them.

In the normal non-client-preset route of the LSP we handle field-suggestions slightly different, we add in fragment spread suggestions and filter out fields that are already present in the selection-set (unless you are typing an alias).

The Fragment suggestions do not seem feasible as we have all fragments of the application in memory, this might just be a bit too costly to compute... not even mentioning the noise of all fragments that can be spread on a certain type if it's coming from the whole application.

We however could provide value by filtering out duplicate fields, the logic for that can be found here and the code to alter is found here.

A solution we'll need to provide is similar to this where we can define externalFragments which in this case would be the global-fragments

In GraphQL-Hive a modular approach is used to maintain the schema. We should load it which can be done with graphql-tools and a glob watcher to hot-reload it.

Currently all fields display information when hovered, apart from fragment-spreads we should support this as well and maybe display all fields.

In VS Code, GraphQL field descriptions in IntelliSense have broken syntax highlighting:

Currently if we have leading fragment references the suggestions cursor-position will be erroneous

Template strings containing GraphQL queries that have a leading comment /* GraphQL */ do not have any sort of IntelliSense you would expect this plugin to provide. If you replace the comment with a qgl template string tag function, the IntelliSense starts working. The GraphQL client we're using, graphql-react, (like several other GraphQL clients) doesn't use template string tag functions for GraphQL; it just uses a string for the query.

Currently we execute the introspection once when we have a URL or URL-object for the schema. When we use file-based we leverage an FS.watch, we should have some periodic refetch atleast configurable for the URL-based as well.

Currently we only support .json introspections as well as normal text which we assume is a GraphQLSchema, however it's most likely worth supporting a URL format as well so we fetch the introspection and treat it as JSON.

One of the things that can turn out to be difficult in normalized caching is when people aren't querying the key-fields, we could write a heuristic that looks at the selection-sets and warns when we see the schema offers an ID! field but that field isn't queried. I would also add a few defaults like key, id, uid and _id

We'd put this behind an option so people can opt-in to this behavior.

When triggering autocomplete, I get multiple for the same option

We should show descriptions for FragmentSpread and Field suggestions when we're auto-completing. I'm not entirely sure whether this is possible but it would help DX a lot 😅

For files in the tree we could use fs.watch

I saved my file but seems like it was being overwritten by the plugin at the same time:

Currently when there's an interpolated fragment the LSP stops working

• look at scopes
• alternatively resolve manually