Fix dotenv issues

[jkcorrea]

Fixes #257

I don't know two licks about vscode extension development, but this was bugging me and I wanted to take a swing at debugging this. workspaceFolders[0] must contain the proper env file at activation time.. perhaps you could make this path configurable instead.

Don't have the time to debug further, but I think what's happening is either graphql-config or cosmiconfig are loading the env once and for the cwd. However, the extension is running with cwd at /, so no env is loaded.

[sanderkooger]

I just tested with a Json config, and it seems to only function on a JS config.

Is there a way to make env vars work for all config file types?

{
  "schema": "src/generated/graphql.schema.json",
  "extensions": {
    "endpoints": {
      "thisisfashion": {
        "url": "${HASURA_URL}",
        "headers": {
          "x-hasura-admin-secret": "${HASURA_ADMIN_SECRET}"
        }
      }
    }
  },

results in: NetworkHelper: operation: query NetworkHelper: endpoint: undefined

If I directly add the variable data it does work. It seems like the plugin does not load the vars from the .env file. I also tried adding vars

[mvaivre]

I've tried your patch, but it prevents the extension from starting... So, still not able to get my .env file to be read unfortunately!

[acao]

@sanderkooger this feature for env replacement has been deprecated in graphql-config v3. it added a lot of complexity and latency to reading config. you can talk to them about re-adding it there, perhaps a custom loader would allow legacy support for this?

the current strategy is to use commonjs (typescript is on its way i believe) and process.env to replace this behavior, as per my discussions with maintainers

CC @ardatan @kamilkisiela @urigo

[acao]

@jkcorrea perhaps you can take this bug up with the graphql-config folks? telling a vscode process to process.chdir() seems like it could cause a LOT of problems.

the language server and this client are where we are invoking the dotenv module to load this config most of the time, though this config is also used by the client process for executing queries. the multi-workspace support is currently broken in the language server which is likely the cause of your issues.

the better solution to this problem would be for graphql-config to itself handle loading .env optionally when loading config programatically. then the question of runtimes is no longer an issue. you instead can just configure the dotenv module to use the workspaceFolder paths for each config, rather than trying to change process directory. the only caveat here is that multiple env files with clashing keys can't be loaded into the same process (such as a single extension process handling multiple workspaces, or the single language service instance that it invokes)

[binary64]

I just managed to fix it with this

const path = require('path')
require('dotenv').config({ path: path.join(__dirname, ".env")})

place that at the top of your graphql.config.js

[acao]

I think perhaps graphql-config 4 which we are using now solves this problem?

[acao]

Ah, another problem with this approach is that it only changes things for the client and not the language server. Both have to load graphql config seperately