Autocomplete not working about vscode-graphql

[ntziolis]

@nathanchapman Sry if I was not clear:

• no need to create an introspection json file, but you need a .graphql schema file that does NOT require stiching (meaning all the datamodel.graphql types are already included)
• there is no need to run the server to create such a schema file, below you find the code we use todo it and we simply run it every time we change the schema on the server and or in prisma

import * as fs from 'fs';
// tslint:disable-next-line:no-implicit-dependencies
import { GraphQLSchema, introspectionQuery, printSchema } from 'graphql';
import { GraphQLServer } from 'graphql-yoga';
import resolvers from './resolvers';

const server = new GraphQLServer({
  typeDefs: './src/schema.graphql',
  resolvers,
  resolverValidationOptions: {
    requireResolversForResolveType: false,
  },
});

// any requiers as for some reason there seems to be different typings used
const schemaString = printSchema(server.executableSchema as any, {
  commentDescriptions: false,
});

fs.writeFileSync('../web/src/generated/schema.graphql', schemaString, 'utf-8');
fs.writeFileSync('../server/src/generated/public.graphql', schemaString, 'utf-8');

Advantages of using this script:

• you actually remove the step of running get-schema on the client side.
• you can run the script in a CI environment and and verify that client side code is still valid against the most current schema (using apollo codegen to validate our queries agains the freshly generated schema)

[caioflores]

@nathanchapman how did you solve this problem? We use merge-graphql-schemas, so we have the same problem.

[divyenduz]

Please notify me via a comment here if this issue still exists, I will reopen the issue.

[divyenduz]

@nathanchapman : Can you please share your GraphQL config file? This extension also allows specifying globs in the GraphQL config file. I take it that this is not the most optimal developer experience but I want to pin point the issue.

Re Apollo Fedaration, can you please create a feature request for it? Then someone from the community can pick it up, you can also take a dig at it if you want to.

[ntziolis]

I would recommend creating a script generating a schema into a file. There is really no way around that as dynamic stitching for schema input is not supported. We have tried various different ways, best was to leverage printSchema from graphql package. You can just thrown an executable schema into it and it will generate a full schema file

[nathanchapman]

We have no need/desire for generating a schema.json within these individual projects. This would also force us to have the server running locally during development for accurate results. There's no way to get auto-complete working with a set of files? The other features work just fine with this approach.

[nathanchapman]

I don't think I explained it well enough in the initial issue. These aren't client side projects. They're libraries that are pieces of the schema (type definitions and resolvers) that are merged to create a server. These "data sources" are one piece of the data model so we don't have a single giant project with 1000+ type definitions and resolvers that are near impossible to reason about. The issue here is that there is no schema.graphql.

I still don't see why autocomplete wouldn't work given a directory with all of the .graphql files.

[ntziolis]

@nathanchapman The suggestion wasn't client specific, also applies for server. Right now the downstream, tools used to build this extension do NOT support stiching schemas together (the extension team doesn't control these downstream pieces, I have tried all currently available graphql extensions and all have the same issue). Your only option is to create a single schema.graphql file containing all your schema.

They're libraries that are pieces of the schema (type definitions and resolvers) that are merged to create a server.

So you already create an executable schema somewhere, the only fix as of now to get autocomplete support is to generate a schema file by running printSchema on the executable schema.

I agree its a workaround, but there is no other AFAIK.

[nathanchapman]

Again, the server is not always running during development so this would provide:

1. inaccurate results compared to the active files in the directory
2. an extra file that has to constantly be regenerated and has no value over the type definition files in the directory

I don't this this is a viable solution.
I guess I'll have to fork the repo and rework some things. If it makes sense to merge that back in, I'll create a PR.

Thanks for the discussion!

[ntziolis]

@nathanchapman Totally get the extra file thing, that said I think you missed my comment about NOT needing to run the server at all when creating this file. Generation of the script can be done without exposing a http endpoint just in memory. Not sure if this changes anything for you as it still leaves you with that extra file.

[nathanchapman]

For our use case, we would have to have something constantly running that regenerates the schema file during development otherwise we'd suffer from inaccurate autocomplete results. And I don't really want to force developers to have to remember to run another script while they're working on these reusable/composable pieces of the GraphQL schema.

[nathanchapman]

@caioflores Unfortunately, no solution yet 😞

[nathanchapman]

@divyenduz still exists!
Other tools, like https://github.com/dotansimha/graphql-code-generator will pickup all specified files by using globs in the configuration:

schema: src/schemas/**/types/*.ts

In this example I'm wrapping GraphQL SDL in gql-tag inside of TypeScript files and it's picking them up.

If the autocomplete here wasn't limited by a singular schema.json / schema.graphql file, it would work for people who are breaking their schemas up into smaller pieces and merging them when creating the server. I'm also curious: are there are any plans to support Apollo Federation in the future?