Js-graphql-intellij-plugin: Pull in environment variable from dotenv .env file

[igorakkerman]

Hi, here's an enhancement proposal on specifying environment variables:

Currently, if a variable is used in _.graphqlconfig_ and is unset, a dialog pops up to enter the value of this variable.

Proposal:
If a .env file exists (as is used by dotenv, for instance), automatically use the values of the environment variables specified in that file. If such a file exists and it contains an API access token of the appropriate name, then, most probably, the application is also using that same token for the same purpose.

I'd be curious on everybody's opinions on this.

[nifanic]

If part of my .graphqlconfig is—

"headers": {
  "Authorization": "bearer ${env: TOKEN}"
}

Where is the plugin (installed in WebStorm) trying to read the TOKEN from?

[jimkyndemeyer]

@nifanic The plugin will show a dialog once an environment variable's value is needed, e.g. when you need to authenticate against the endpoint. So you'll see it if you introspect the endpoint, and when you use the green play button to execute queries and mutations.

I opted to show the dialog each time as the it would also be annoying to have to restart the IDE in case a new value needs to be entered. But I made sure to focus the dialog such that you can simply press enter to close it using the current value.

[nifanic]

Yup, I've seen the dialog box in action (with a hint to pass the token with CLI), however, I'd agree with @igorakkerman that .env for accessing tokens would be more elegant solution.

Similar plugins (but for VS Code) use .env for tokens by default.

Any plans to implement .env support at all?

[jimkyndemeyer]

Agreed that this would be useful, but no concrete plans at this time.

I'm balancing this project against a number of other commitments, which currently means keeping the plugin compatible with changes in the IntelliJ Platform is just about the time I can find.

I'd be happy to take a PR for this. The feature appears to be pretty isolated from some of the more complex language tooling, so could be a good "first issue".

[jbrunken]

On my Webstorm install (Mac), I don't get a dialog asking me to provide the ENV variables.

[mellson]

I've added a pull request to add this feature here https://github.com/jimkyndemeyer/js-graphql-intellij-plugin/pull/426
You're welcome to give this a spin if you feel comfortable installing the plugin from a zip file - download the plugin here

[vepanimas]

I merged a PR, thanks to @mellson! I hope I'll release it during this week.

[Vadorequest]

@vepanimas @mellson Any plan to support .env.local file?

Those tokens are usually sensitive and it's a bad practice to store them in .env (which is usually being tracked by Git), and many people use .env.local (or other, like .env.test).

Having the ability to select the file to use would be even more flexible. Something along the lines of:

{
  "schemaPath": "schema.graphql",
  "dotEnvPath": ".env.local"
}

[vepanimas]

@Vadorequest hi! We use this library now, it recommends not to commit env file (based on 12 factor app methodology):

Q: Should I commit my .env file?

A: No. We strongly recommend against committing your .env file to version control. It should only include environment-specific values such as database passwords or API keys. Your production database should have a different password than your development database.

If you really need it, we could think about a hierarchy of file name precedence, I'd suggest creating a new issue for this if you don't mind.

[Vadorequest]

The Next.js framework recommends committing .env (and I agree with that), while providing other files such as .env.local which are not meant to be committed.

Here is an example of how I use .env files, this pattern is strong and safe.

• https://github.com/UnlyEd/next-right-now/blob/v2-mst-aptd-at-lcz-sty/.env
• https://github.com/UnlyEd/next-right-now/blob/v2-mst-aptd-at-lcz-sty/.env.local.example

I'm still copy/pasting the secret from my .env.local file to the popup input manually at this time, I'm not in a huge need for this feature (even if that'd be nice 😉).

Although, I feel bad every time I see the readme because it says things while I'm doing the opposite 😄 (and encouraging people doing the opposite). I guess that's a matter of opinions and tools, too.

---

A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.

Tracking the .env doesn't necessarily go against that. I believe the author consider it a best practice because of how it can be misused, but none of our sensitive information are tracked by Git, ever.

[mellson]

@Vadorequest I think I can add the ability to look for additional .env files.

I'm thinking it's the files in the list below we should look for in that order. Do you agree? And am I missing any files here?

.env.production.local
.env.production
.env.development.local
.env.development
.env.local
.env

[Vadorequest]

I think .local should always take precedence, because that's the local setup for your own machine and you usually use those for overriding settings. But maybe the list you wrote is ordered from most priority to lowest priority? (would make sense since .env works that way)

Would it load all those files (when found) or only one (the first found)?

I'm not sure it it makes sense to load production/development files, because the GrapQL intelliJ plugin is for local development only (AFAIK). So I'd leave out the .env.production files.

So, my list from most priority to lowest would rather be:

• .env.local
• .env.development.local
• .env.development
• .env

Does that make sense? 😄

[mellson]

@Vadorequest that makes sense. ~I'll do a pull request within the next few days.~ Pull request here #446