VSCode Plugin: Loading Schema Twice #801

alexlafroscia · 2018-12-04T21:32:13Z

It seems like the schema is being loaded twice by the VSCode plugin. As soon as I load the plugin, I get the following error:

Type "AddLinkPayload" already exists in the schema. It cannot also be defined in this type definition.

This is the first type in my schema, and is only defined once in the file. This is leading me to think that the file is attempting to be loaded more than once, adding to the existing schema and causing the error.

alexlafroscia · 2018-12-04T21:43:00Z

This is where the error is coming from:

apollo-tooling/packages/apollo-language-server/src/project/client.ts

Line 140 in 5d1cb7a

this.schema = extendSchema(this.serviceSchema, this.clientSchema);

alexlafroscia · 2018-12-04T21:49:09Z

I currently have a configuration that looks like this:

module.exports = {
  client: {
    includes: [
      './packages/original-series-engine/addon/**/*.graphql',
      './packages/original-series-engine/addon/**/*.js'
    ],
    service: {
      name: 'Original Series Workflow API',
      localSchemaFile:
        './packages/original-series-engine/addon/graphql/schema.graphql'
    }
  }
};

The documentation seems to suggest that I could leave out my service definition here, because

By default, the VS Code extension will look for all files under ./src to find both the operations and schema definitions for building a complete schema for the application.

But in practice, that doesn't work, as I get a complaint that

No provider was created for config

If I provide a service with nothing but a name, I get an error about only absolute URLs being supported.

If I make service a String instead, I get a complaint about not having Engine configured.

igorp1 · 2018-12-17T14:06:47Z

were you able to find a solution to this @alexlafroscia? I'm running into the same issue

alexlafroscia · 2018-12-17T17:46:25Z

Nope, unfortunately not. I've been flip-flopping between this and the Prisma VSCode plugin, because both have issues for me. I'm currently on the Prisma one, which is working a little better!

igorp1 · 2018-12-17T17:54:09Z

I've been doing a lot of back and forth between those 2 as well. I think our issue might be solved with the next release based on this commit that documents our use case with service nested into client. It is tagged with vscode-apollo@1.2.8 current extension version is 1.2.7, so... fingers crossed.

Would you mind sharing what you have on your .graphqlconfig to get the Prima extension to work properly?

alexlafroscia · 2018-12-17T18:53:10Z

Sure -- not that this is specific to our application in some ways, which is a monorepo of Ember packages

{
  "projects": {
    "indie-engine": {
      "schemaPath": "packages/indie-engine/addon/graphql/schema.graphql",
      "includes": ["packages/indie-engine/addon/**/*.*"],
      "excludes": [
        "packages/indie-engine/addon/graphql/schema.graphql",
        "packages/indie-engine/addon/graphql/fragments.js"
      ],
      "extensions": {
        "endpoints": {
          "dev": "http://localhost:3001/api/workflow/graphql/",
          "test": "http://localhost:4200/api/workflow/graphql/"
        },
        "generate-fragments": {
          "output": "packages/indie-engine/addon/graphql/fragments.js",
          "generator": "js"
        }
      }
    },
    "original-series-engine": {
      "schemaPath": "packages/original-series-engine/addon/graphql/schema.graphql",
      "includes": ["packages/original-series-engine/addon/**/*.*"],
      "excludes": [
        "packages/original-series-engine/addon/graphql/schema.graphql"
      ],
      "extensions": {
        "endpoints": {
          "test": "http://localhost:4200/api/workflow/original-series/graphql"
        }
      }
    },
    "workflow-components": {
      "schemaPath": "packages/workflow-components/tests/graphql/schema.graphql",
      "includes": ["packages/workflow-components/addon/**/*.*"],
      "extensions": {
        "endpoints": {
          "test": "http://localhost:4200/api/workflow/original-series/graphql"
        }
      }
    }
  }
}

igorp1 · 2018-12-17T18:55:28Z

Thank you for sharing @alexlafroscia, this is def helpful

JakeDawkins · 2019-03-11T17:03:49Z

Sorry we haven't responded to this until now! Has this issue been resolved in the past couple months?

Hotell · 2019-03-12T09:56:03Z

it's not loading just twice... 3 times in my project and it doesn't work either. it still uses old schema...

JakeDawkins · 2019-03-18T15:11:20Z

@Hotell Are you also getting the error for it trying to overwrite existing types or just the multiple loading notifications?

benmosher · 2019-03-29T11:57:37Z

@JakeDawkins I just installed the VSCode extension this morning and am seeing this issue.

I am working around the error with

module.exports = {
  client: {
    service: {
      name: 'my-schema',
      localSchemaFile: './src/schema.graphql',
    },
    // hack: remove .graphql from includes to avoid duplicate schema errors
    includes: ['./src/**/*.{ts,js,tsx}'],
  },
}

but I think this has the effect of disabling the language features when editing the schema itself. They work great from the gql tag in JS/TS source now, though, and no errors in the extension console.

Edit: I thought maybe this was unique to localSchemaFile but it seems to happen with setup to load the schema from the server also.

JakeDawkins · 2019-04-02T14:03:33Z

@benmosher @alexlafroscia It looks like both of your issues are from the language server trying to load the schema from localSchemaFile and running into it again because it matches the includes glob, which by default picks up graphql files in src/

A Workaround for this would be to do one of the following

move the schema outside of src (which we do usually)
add an item under the excludes key to explicitly prevent reloading of the schema.
remove the localSchemaFile entry under service, and let the language server find the schema by itself using includes

A more permanent fix would be to track the URIs of the loaded schema files to make sure there's no accidental reload, but I'll have to look into that. I'm not sure how much extra work would be required yet.

JakeDawkins · 2019-04-02T14:10:41Z

Also, quick note, we don't fully support editing schema files right now. So things like typeahead and type information in schema files loaded by localSchemaFile shouldn't work (although we need to add support for that soon 🙂).

damassi · 2019-04-21T06:39:40Z

Nice! Explicitly excluding the local schema in excludes while pointing to remote schema works great.

dylanwulf · 2019-05-06T16:37:03Z

I am getting this issue whenever I open a file diff that contains typeDefs from the source control sidebar

DanielHabenicht · 2019-06-23T01:56:46Z

That's really inconvenient and renders the plugin useless for me.

@JakeDawkins

In my project that does not work. I am working in a Monorepo and have put the apollo.config.js in my root, so there is no ./src folder. The .graphql file (in one of the project folder roots, but definitely not in a src folder) is picked up by the extension nevertheless.
Does not work as described here: Type "Mutation" already exists in the schema. It cannot also be defined in this type definition. #812 (comment)
That's not working if you only want to work with the local schema.graphql as the extension complains if no localSchemaFile is provided.

JakeDawkins · 2019-06-26T16:22:37Z

I'm sorry you're still seeing this @DanielHabenicht. I'm not sure what's going on. Is there a repo you can point me to with the reproduction of this?

Does your monorepo have multiple apollo projects inside it? If so, having a single apollo config at the root of the repo won't work. Config files only support single projects.

Maybe you could also paste in your config here to help me figure out what's going on.

joefiorini · 2019-07-05T13:45:03Z

FWIW I'm seeing this same issue loading a project that gets the schema from an endpoint URL instead of localSchemaFile. I do not have a schema file under src and currently my config specifically only includes ts & tsx files and excludes any graphql files. Here's the config:

module.exports = {
  client: {
    service: {
      name: "feature-keeper-api",
      endpoint: {
        url: "http://localhost:8000/.netlify/functions/graphql",
      },
    },
    includes: ["./src/**/*.{ts,tsx}"],
    excludes: [
      "./src/**/.test.{ts,tsx}",
      "./src/@types",
      "./src/functions",
      "**/*.graphql",
    ],
  },
}

I also see the error running client:codegen which is the majority reason I am using apollo-cli.

EDIT:

Tried changing the service config to:

    service: {
      name: "feature-keeper-api",
      localSchemaFile: "./schema/api.graphql",
    },

but I'm still seeing the same issue.

The repo where I'm having the issue is private but I'm happy to share it with an apollo dev if it would help troubleshoot this issue. Let me know.

EDIT:

I tried removing all .graphql files from my codebase and client:codegen still fails with the same error, so I can confirm it's not loading additional schema files.

I think I figured out my problem. One of my excludes (./src/functions) is pointing to a folder, but apparently that isn't good enough. Changing it to ./src/functions/**/* is necessary to actually exclude it. I have typedefs in a .ts file in that folder for my schema.

lorensr · 2019-08-08T07:14:12Z

This was fixed for me by adding excludes. From:

module.exports = {
  client: {
    service: {
      name: 'api',
      url: 'http://localhost:4000/'
    }
  }
}

to:

module.exports = {
  client: {
    service: {
      name: 'api',
      url: 'http://localhost:4000/'
    },
    excludes: ['**/*.graphql']
  }
}

tvvignesh · 2019-11-10T14:35:04Z

@JakeDawkins I have been struggling with the same problem as well. Adding excludes did not solve the problem for me (may be because I am using the registry?)

I am using the Apollo Schema Registry with Apollo Federation

My apollo.config.js looks like this:

module.exports = {
    client: {
        service: 'tctest-2@poc',
        excludes: [
            '**/*.gql',
            '**/*.graphql',
            '**/node_modules/**/*',
            '**/__tests___/**/*'
        ]
    }
};

Screenshot of the error in vscode apollo graphql extension:

The VSCode extension keeps restarting again and again for 5 times and then it says the server will not be restarted (screenshot below). Then I have to restart the window again to get it back up. Suggestions work until it crashes.

This is the version of libraries I am using:

    "apollo-cache-inmemory": "^1.6.3",
    "apollo-client": "^2.6.4",
    "apollo-link-http": "^1.5.16",
    "graphql": "^14.5.8",
    "graphql-tag": "^2.10.1"

Also, I see Apollo GraphQL listed twice in the Outputs section of VSCode (similar to what is mentioned here: #690 (comment)) - Is it loading once for registry and once for local graphql files?

Thanks in advance.

tvvignesh · 2019-11-10T16:38:22Z

@JakeDawkins I have been struggling with the same problem as well. Adding excludes did not solve the problem for me (may be because I am using the registry?)

I am using the Apollo Schema Registry with Apollo Federation

My apollo.config.js looks like this:
module.exports = {
    client: {
        service: 'tctest-2@poc',
        excludes: [
            '**/*.gql',
            '**/*.graphql',
            '**/node_modules/**/*',
            '**/__tests___/**/*'
        ]
    }
};
Screenshot of the error in vscode apollo graphql extension:

The VSCode extension keeps restarting again and again for 5 times and then it says the server will not be restarted (screenshot below). Then I have to restart the window again to get it back up. Suggestions work until it crashes.

This is the version of libraries I am using:
    "apollo-cache-inmemory": "^1.6.3",
    "apollo-client": "^2.6.4",
    "apollo-link-http": "^1.5.16",
    "graphql": "^14.5.8",
    "graphql-tag": "^2.10.1"
Also, I see Apollo GraphQL listed twice in the Outputs section of VSCode (similar to what is mentioned here: #690 (comment)) - Is it loading once for registry and once for local graphql files?

Thanks in advance.

Finally got it solved. It was because I was writing my code in Typescript in src (.ts) and it was getting built to javascript in dist (.js) and Apollo GQL was going through both of these causing the duplication. I added '**/dist/**/*.js', to excludes and then it worked.

tdnghia98 · 2020-03-05T09:23:36Z

So weird that the issue is still not resolved

niclaspallin · 2020-05-30T11:00:25Z

Im having this issue as well. I tried most combinations in apollo.config.js. I finally got it to work, I'm not sure how it finds all the schema definitions but I have an isomorphic react app, so the way I solved it was to only include files under the client directory, excluding all server files.

JakeDawkins · 2020-06-03T21:03:40Z

@niclaspallin the current config setup only really allows for a single project per apollo config file. so if you have a service and a client project under a single apollo.config glob, it makes sense why this error would be happening for you.

HosseinAgha · 2020-12-16T17:07:09Z

remove the localSchemaFile entry under service, and let the language server find the schema by itself using includes.

@JakeDawkins Doing this generates the following error for me:
Service stats could not be loaded. This may be because you're missing an apollo.config.js file or it is misconfigured. For more information about configuring Apollo projects, see the guide here (https://go.apollo.dev/t/config).

My serverside schema is defined in .gql files and I don't have any client-side for now. I tried reading the schema from my GraphQL service and excluding the .gql files in src but the language server will be disabled for those files.

module.exports = {
  client: {
    excludes: ['src/**/*.gql'],
    service: {
      name: 'local',
      url: 'http://localhost:port/graphql',
    },
  },
};

So if I exclude the files I get nothing from the language server (no jump to definition, no autocomplete) and if I remove the service definition I get the above error.

macrozone · 2021-02-15T15:37:02Z

i am also shocked by the current state of the vscode extension. It sometimes work, and when it works its fantastic, but as soon as it gets a bit more complicated like having a project that requires two graphql endpoints, it fails and in a very weird and inconsistent way.

I tried to configure two apollo.config.js, but that leads to strange hard to reproduce errors.

Also just having one apollo.config.js and adding excludes to ignore queries that use the other graphql endpoint does not work at all. excludes seem to have no effect at all.

I think this needs a major overhowl and maybe the maintainers need to dog-feed it to themselves (in particular the multi-endpoint use-case).

If the core team cannot maintain it, it would be fair for the community that this is announced accordingly.

haf · 2021-09-07T08:41:21Z

Related hasura/graphql-engine#6466

haf · 2021-09-07T08:44:28Z

From the comments I realised that it reads the schema file twice if that file is under src/

Just exclude it:

jgzuke · 2021-10-06T02:02:43Z

Realizing I forgot to come back to close this! This was fixed and released a while ago in apollographql/vscode-graphql#8. If you're still seeing this error please open a new issue over on the new repo! Thanks for all the help investigating 😄

JakeDawkins added the 🗒️ component - vscode related to editor tooling label Apr 2, 2019

JakeDawkins self-assigned this Jul 10, 2019

tvvignesh mentioned this issue Apr 6, 2020

Avoid crashing the VSCode extension #1874

Open

abernix added 🔨 cli related to the CLI itself and removed 🔨 cli related to the CLI itself labels Jan 20, 2021

jgzuke mentioned this issue Jul 28, 2021

fix: Don't load localSchemaFile as part of project code apollographql/vscode-graphql#8

Merged

haf mentioned this issue Sep 7, 2021

Apollo Client in VSCode / schema introspection fails hasura/graphql-engine#6466

Closed

jgzuke closed this as completed Oct 6, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VSCode Plugin: Loading Schema Twice #801

VSCode Plugin: Loading Schema Twice #801

alexlafroscia commented Dec 4, 2018

alexlafroscia commented Dec 4, 2018

alexlafroscia commented Dec 4, 2018 •

edited

Loading

igorp1 commented Dec 17, 2018

alexlafroscia commented Dec 17, 2018

igorp1 commented Dec 17, 2018

alexlafroscia commented Dec 17, 2018

igorp1 commented Dec 17, 2018

JakeDawkins commented Mar 11, 2019

Hotell commented Mar 12, 2019

JakeDawkins commented Mar 18, 2019

benmosher commented Mar 29, 2019 •

edited

Loading

JakeDawkins commented Apr 2, 2019 •

edited

Loading

JakeDawkins commented Apr 2, 2019

damassi commented Apr 21, 2019

dylanwulf commented May 6, 2019

DanielHabenicht commented Jun 23, 2019

JakeDawkins commented Jun 26, 2019

joefiorini commented Jul 5, 2019 •

edited

Loading

lorensr commented Aug 8, 2019

tvvignesh commented Nov 10, 2019 •

edited

Loading

tvvignesh commented Nov 10, 2019

tdnghia98 commented Mar 5, 2020

niclaspallin commented May 30, 2020

JakeDawkins commented Jun 3, 2020

HosseinAgha commented Dec 16, 2020

macrozone commented Feb 15, 2021

haf commented Sep 7, 2021

haf commented Sep 7, 2021

jgzuke commented Oct 6, 2021

VSCode Plugin: Loading Schema Twice #801

VSCode Plugin: Loading Schema Twice #801

Comments

alexlafroscia commented Dec 4, 2018

alexlafroscia commented Dec 4, 2018

alexlafroscia commented Dec 4, 2018 • edited Loading

igorp1 commented Dec 17, 2018

alexlafroscia commented Dec 17, 2018

igorp1 commented Dec 17, 2018

alexlafroscia commented Dec 17, 2018

igorp1 commented Dec 17, 2018

JakeDawkins commented Mar 11, 2019

Hotell commented Mar 12, 2019

JakeDawkins commented Mar 18, 2019

benmosher commented Mar 29, 2019 • edited Loading

JakeDawkins commented Apr 2, 2019 • edited Loading

JakeDawkins commented Apr 2, 2019

damassi commented Apr 21, 2019

dylanwulf commented May 6, 2019

DanielHabenicht commented Jun 23, 2019

JakeDawkins commented Jun 26, 2019

joefiorini commented Jul 5, 2019 • edited Loading

lorensr commented Aug 8, 2019

tvvignesh commented Nov 10, 2019 • edited Loading

tvvignesh commented Nov 10, 2019

tdnghia98 commented Mar 5, 2020

niclaspallin commented May 30, 2020

JakeDawkins commented Jun 3, 2020

HosseinAgha commented Dec 16, 2020

macrozone commented Feb 15, 2021

haf commented Sep 7, 2021

haf commented Sep 7, 2021

jgzuke commented Oct 6, 2021

alexlafroscia commented Dec 4, 2018 •

edited

Loading

benmosher commented Mar 29, 2019 •

edited

Loading

JakeDawkins commented Apr 2, 2019 •

edited

Loading

joefiorini commented Jul 5, 2019 •

edited

Loading

tvvignesh commented Nov 10, 2019 •

edited

Loading