Use extension without config file

[emil-nasso]

Is there any way to use the extension without a config file?

I work in an environment with multiple micro-services that uses graphql. The projects all have a single schema.graphql-file but there is no need for a config file for graphql.

If I just open a .graphql file in vscode, syntax highlighting works, but the "goto definition" feature doesn't. It seems like I need a config file for that to work.

Isn't there any way to get the extension to work with .graphql files when you just have one of those in the project and don't need a config file?

I have never had a config-file in any of my project and I have no idea what the purpose of it is. Is it framework specific? I find nothing in the graphql specification about this config-file. Is this extension for a specific framework?

[orta]

You're welcome to use a field 'graphql' in the package json, and if you'd like to learn about why the config exists see: https://www.graphql-config.com/docs/user/user-introduction

[dncrews]

@orta do you happen to have a link to a good website or maybe an older cached version that was stable maybe? From those docs, I still don't understand anything that's going on here. The docs you linked to are mostly either

1. full of broken links
   • "to understand the point of this, click here"... 404
2. don't explain anything
   • "to understand how to use this, click here"... page with zero information on it and links to github folders without readmes

I still have zero understanding of what that file is supposed to do or why it's valuable in anyway, and I feel like I've read everything on it.

---

Anyway: to back up OP's point, if I add a config file that looks like this:

schema: vscode-graphql doesn't care about me

the plugin works exactly as if I pointed it to real schema files. That is my actual file. There's no change in any functionality from this file, which points to actual documents and schema:

schema: "src/schema.graphql"
documents: "src/**/*.{graphql,js,ts,jsx,tsx}"

If the contents of the file don't matter, why bother requiring it?

[acao]

all about this! it's already on the roadmap even, essentially. i've added this to the initiative.

the language server, and thus this extension and many extensions across various IDEs that use this language server need to specify at least a schema for now. like @orta pointed out, that can be specified in a config file or in package.json

on the roadmap we have plans to make the language server work without schema present. currently, the only feature you would get from a config-less graphql project is highlighting, is that all you want?

I'm adding labels for both graphql-language-service-server and vscode-graphql, since this implies enhancements in both projects, as well as our third party IDE plugin users (nvim, emacs, sublime, etc), who usually use graphql-language-service-cli. it should come as part of the next major version release, because we plan on changing the graphql-language-service-interface method interfaces (getAutocompleteSuggestions, getHover, etc) to accept an easier-to-expand-on object argument interface rather than using ordered arguments, and making schema argument optional for these methods is part of the goal of this!

[dncrews]

currently, the only feature you would get from a config-less graphql project is highlighting, is that all you want?

As OP described, syntax highlighting already works without a file today, so no, that's not what I'm asking for. Adding a file with a property called schema that points to nowhere seems to add everything else, so when you say it requires a file and schema I don't understand. This is the stuff that seems like it should work without a file... since it works without a valid file.

When I say "everything else" it is worth noting that I'm building the server and not the client, so I assume I just may not know what else I'm missing out on.

[acao]

Ohh I understand better what you mean now. Yes the problem is still that schema is required for the lower level interfaces, and your workaround has revealed how unintelligent this is. This unfortunately requires breaking changes to publicly used interfaces, haha, but I see why it seems silly

[emil-nasso]

@acao Yup, all I want is syntax highlighting and to be able to ctrl + click to go to a definition (within the same file I clicked in). It would be great if it could be done. :)

I "hacked" a solution for this, to get the plugin up and running. I added a .graphql file in my home-directory and just added the following to my user settings-file in vscode:

"graphql-config.load.filePath": "/path/to/global/.graphqlrc.yml"

That way, I didn't have to add, commit, and try to get merged a .graphqlrc-file (or package.json change) that didn't really add much (apart from support for a plugin in my personal editor) to 20-30 repositories. :)

[acao]

Ah yes, the multi-workspace support still needs to be added, that would explain your issues. Highlighting, autocompletion and jump to definition should all be working, and if not it’s a config issue, or lack of multi-workspace support. Hopefully another maintainer can help you as I am not able to work at the moment

[michael-watson]

Anything I can do to help with this issue? I don't want any more config files in my project just to find and replace

[acao]

@michael-watson I will let you know soon, this is on the roadmap for this year! multi root workspaces is a definite. config-file free is a much bigger ask of course.

for now, use the package.json graphql config strategy if you want to avoid additional config files

[hlshen]

Our team is attempting to do away with a user visible config file as well. One of our approaches was to generate a yaml in our "generated files" directory, but the encapsulating folder is user defined. Is there a way to programmatically set the rootDir that is being searched for a config file?

[hlshen]

never mind, found you can pass env vars to the server

[acao]

though it might not work for everyone here, don't forget you can use package.json if it's just a matter of keeping the config file count low. this new release includes much more mention of this in the readmes. for e.g.

"graphql": {
   "schema": ["https://localhost:8000/api/graphql"],
   "documents": ["./src/**/**.graphql.{ts,js,tsx,jsx,mjs,graphql}"]
}

can you show an example of how you achieved this with env vars I'm curious, I'd like to document it. it just that the platform provides its own env vars and you can use them in the config file in a way that is consistent for all users.

also remember that graphql configs can be programattic, so you can have this for example:

import { defaultLSPConfig } from '@myplatform/graphql'
export default defaultLSPConfig()

mid term:

first will come a "config file free" mode, where you can configure the server entirely with the LSP client settings for vscode-graphql.* and graphql-config.* (vscode, nvim, etc). then you can actually run another custom vscode extension alongside ours after this, and programmatically set user configs for these scopes using the extension api (I think you can do this?)

long term:

then "configless" mode will come after, and set a new convention - without a graphql config file, package.json graphql entry, or client settings config, THEN it will start with looking for ./schema.graphql in the workspace root, and then try http{s}://localhost:${PORT:8000}/graphql (maybe try a few common web dev ports in parallel just for fun, like 3000 etc), and including all files as documents with common ignore rules across language ecosystems. graphql playground 2.x rewrite actually had something like this kind of, when playground is configured without a URL. I would love to do the same for inline execution extension (and the new version of the exec extension i have planned :)), as well as graphiql itself eventually, but it seems the LSP server and vscode/etc need it most!

and lastly, "schemaless" mode improvements are in order- where same-file capabilties and other sensible defaults should still work without a schema. this may be even more comparable to tsconfig.json-free typescript, or maybe even checkJs: true without as much guesswork

(bonus: I have a theory that somewhere in these efforts, the path to a vscode web mode for graphql will become much clearer)

improved logging here would show this logic flow in output, but it would be cool to provide more visual feedback in some way without further cluttering the bottom status bar. perhaps there can be a command shortcut where it prints a simple table with diagnostics about your LSP server instance... damn that would be great for debugging too!

also to be clear - though this feature was part of the nice to have scope for the grant, or i think i removed it even, it is definitely something I see planned this year, as it will open so many doors to ease of use, and the autoconfiguration should cover 90% of use cases - vaugely like heroku buildkits or auto-pipelines in gitlab CI and other CI platforms work but much simpler. I could use the typescript language service as a model for config-free as well, but the schema aspect is fundamentally different, whereas typescript can resolve its entire tree of type dependencies statically

i also hope to have more documentation about advanced custom implementations, where you need to autoconfigure the extension to your needs or even custom tailor aspects of the experience for your platform/framework/etc. I worked on this problem with gatsby while I was there in 2019/20 so it became abundantly clear more is needed here.