Hi everyone!
I was just trying to figure out how to configure the new VSCode Extension, but I simply couldn't manage to do so.
That's my situation:
How do I successfully configure this in my apollo.config.js? I've tried everything but somehow it never works.
module.exports = {
service: {
localSchemaFile: './internals/schema.graphql',
},
};
^ This config does not output anything in the debug view.
module.exports = {
client: {
service: {
localSchemaFile: './internals/schema.graphql',
},
}
};
^ This config outputs TypeError: Only absolute URLs are supported - welp
Additionally I receive the following error although I don't wan't to use the Apollo Engine related stuff..
UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error: Unable to find ENGINE_API_KEY
Can someone help me? The docs weren't really helpful about this :(
Might be related to https://github.com/apollographql/apollo-tooling/issues/667 ?
When I take a look at this source code here: https://github.com/apollographql/apollo-tooling/blob/b85fa652f373eafccdbd01d8653e4b54d3388333/packages/apollo-language-server/src/schema/providers/index.ts#L25
Looks like the endpoint configuration option is set by default. That may be causing your TypeError. Can you try to change your config to:
module.exports = {
client: {
service: {
localSchemaFile: './internals/schema.graphql',
endpoint: null
},
includes: [
"client/src/**/*.{ts,tsx,js,jsx,graphql}"
]
}
};
Replace client/src with the path to your source code. This setting defaults to src/**/*.{ts,tsx,js,jsx,graphql}.
Also, apollo.config.js must be located in your project root (as seen by vscode).
Same problem here. I tried it with endpoint: null but same result
@jpaas @jessedvrs I did a little more digging into the whole codebase and determined it is definitely a bug.
Came up with a PR https://github.com/apollographql/apollo-tooling/pull/676 to solve this :)
_EDIT:_ Never mind, it was fixed after VScode restart...
@stnwk this error still happens for me!
My config:
module.exports = {
client: {
service: {
name: 'MYGQL',
localSchemaFile: './src/generated/graphql.schema.json',
includes: ['src/**/*.{graphql,ts,js}'],
excludes: ['**/node_modules/**'],
},
},
};
Error: Error in "Loading schema for MCQL": TypeError: Only absolute URLs are supported
I'm using latest VSCode plugin Apollo GraphQL
Had the same problem, needed to fully restart VSCode after editing the apollo.config.js. Adding endpoint: null had no effect.
My config:
module.exports = {
client: {
service: {
name: 'consumer-app',
localSchemaFile: './schema.graphql'
},
includes: ['src/**/*.gql', 'src/**/*.ts', 'src/**/*.tsx']
}
}
@ktsosno are you saying you're _still_ having this problem after a restart?
You shouldn't have needed to restart vscode after a config change. That should've been fixed a while back. Can you make sure you're up to date on the extension if so?
module.exports = {
client: {
service: {
name: 'server-app',
localSchemaFile: '../../server-app/src/GraphQL/schema.graphql'
}
}
};
I use this config file in a multi root workspace, and I definitely sure, the file path is correct, but still got this error:
🚀 Apollo GraphQL v1.5.2
❌ 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://bit.ly/2ByILPj).
@kazinad I can confirm using a local schema doesn't work for me within workspaces, but does work when I run a project on its own.
@aaronmcadam that should be possible to quick-fix via constructing path programmatically with __dirname:
module.exports = {
client: {
service: {
name: 'server-app',
localSchemaFile: path.resolve(__dirname, '<path to schema>')
}
}
}
This works, because __dirname will resolve to the directory where the actual file resides. No matter what working directory you execute it from.
Thanks for this @joltmode, but I now use graphql-codegen for this tooling instead.
This makes sense though, I think this might be useful for other tools inside workspaces, thanks!
Most helpful comment
@aaronmcadam that should be possible to quick-fix via constructing path programmatically with
__dirname:This works, because
__dirnamewill resolve to the directory where the actual file resides. No matter what working directory you execute it from.