Support monorepos with .graphqlconfig files in each subdirectory

[HosseinAgha]

Actual Behavior

The Graphql Language Server outputs the following error when I define .graphqlconfig files for each project in a monorepo setup:

Request initialize failed with message:  
".graphqlconfig" file is not available in the provided config directory: [path to root of monorepo]

It is working when I create a root .graphqlconfig file with separate projects.

Expected Behavior

According to graphql-config specs I should be able to create .graphqlconfig files in each project of monorepo. It looks like it is not fixed in #24.

Specifications

• GraphQL for VSCode Extension Version: 0.2.1
• VSCode Version: 1.38.1
• OS Name: MacOS

Logs Of TS Server || GraphQL Language Service

Request initialize failed with message: 
".graphqlconfig" file is not available in the provided config directory: [root of monorepo]

[acao]

@danielrearden is this possible in graphql-config@3? I can't seem to find anything that indicates that here:

https://graphql-config.com/usage#config-search-places

as far as I know, in graphql-config@3, it's only possible to use the workaround you indicated. considering we read the graphql config on almost every editor event, it would be very underperformant to search descending directories. possibly this is why we had performance issues with graphql-config@2

the root config is the best option we have here in 3.x, and then vscode-graphql.rootDir set to config/ would be a way to use config/.graphqlconfig as the root config if you want a cleaner top level directory

[danielrearden]

@acao As far as I'm aware, this is not currently supported and would need to be raised as an issue. The spec mentioned by @HosseinAgha is not relevant to v3.

For monorepos, the recommended approach would be to specify projects as shown here in the docs.

[HosseinAgha]

@danielrearden, IMHO this is a wrong approach and is not compatible with the other community tools' behavior.

Imagine the following project structure.

backend
  | - package.json
frontend
  | - package.json
package.json
graphql.config.yml

I use graphql.config.yml to configure my graphql-codegen.
My graphql.config.yml has a frontend and backend project and it exists inside the root directory in order for vscode extension to use it.
The graphql-codegen command will be in a script inside the frontend package.json. It correctly uses the graphql-config in the root but it cannot find the codegen plugins whether I install them in the frontend or in the root.

[acao]

@HosseinAgha so despite organizing your repo into multiple “projects” in a graphql config sense, its still unsuitable? it would seem your config file would have two projects, one for frontend and one for backend, and the codegen config can go in the root project config (so all projects share the config) or the frontend one i guess?

[acao]

are you thinking graphql config should work like babel and eslint? because even babel had the same issue, now you must use rootMode —upwards to use a config that’s in a shared root directory

[pedro-pedrosa]

This request would probably also help me solve my problem of having separate config files for a vscode workspace that contains multiple folders. The reason I want to have separate files in each folder in the workspace is because these folders are controlled by different repositories and I want source control of the config file for each of them

[acao]

why not just have one root config file that require()s all the children files with commonjs?

the effort to implement the feature you ask for would be huge, as we would have to rewrite the server to be able to load from multiple graphql config instances at a time, and then develop our own system of tracking which file belongs to which

[d3dc]

@acao Our projects span multiple people and teams. Same situation as @pedro-pedrosa - A root .graphqlconfig would be outside the scope of individual projects but get very project specific at the same time.

[rxliuli]

I have the same problem. . . This plugin cannot be used normally in monorepo, and the graphql plugin of webstorm supports this, maybe this means that we have to maintain two sets of configurations

[acao]

here is how to support legacy .graphqlconfig:

https://github.com/jimkyndemeyer/js-graphql-intellij-plugin/issues/296#issuecomment-1030844370

users are reporting it working. For multi-workspace support enhancement, please track this in the open roadmap ticket in graphiql monorepo

[rxliuli]

here is how to support legacy .graphqlconfig:

jimkyndemeyer/js-graphql-intellij-plugin#296 (comment)

users are reporting it working. For multi-workspace support enhancement, please track this in the open roadmap ticket in graphiql monorepo

I mean that webstorm supports self-configuration of graphql in the monorepo submodule and takes effect, but this plugin can only be configured in the root directory, so it is said that two configurations may be written, or all vscode must be opened separately when writing graphql query statements at the same time Submodules (this is hard, and getting everyone to use webstorm or vscode is hard)

[acao]

Workspaces support is another issue entirely we are tracking in the language server repository. This is already on the LSP server roadmap. Closing this as a duplicate