-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Env variables appear to be being cached #2959
Comments
I have had this issue when you try to load you can try add this as node options. change "dev": "cross-env PORT=4000 NODE_ENV=development NODE_OPTIONS=\"-r dotenv/config\" DISABLE_LOGGING=true keystone dev", |
Seems the |
@gautamsi , @Vultraz -- Unfortunately that didn't seem to work
traces out
|
@ra-external did you get this resolved? I've not seen any other issues of this and I'm not sure how to help. |
@MadeByMike -- No, I posted it on Stack Overflow, as well in the issue for DotEnv, on the forum fo the IDE I use, and the consensus seemed to be that it was Keystone that was caching it somehow, although someone also suggested it might have something to do with
I haven't had to change any ENV variables in two weeks -- it seems to work fine with adding them -- so I had just let it sit, hoping that an answer would 'appear'. I agree that it's strange, but it was reproducible, that is to say, it persisted for days despite various workarounds. |
Strange. Keystone doesn't do any kind of caching other than what might be provided through Express or something like Next.js if you're using that for an app. Certainly nothing that I imagine could cause this. Is it only happening in your local environment or can you reproduce it on a different host? |
Only my local environment. If you're certain that it's not Keystone, I'll close this. This is the only project where it's happened. The strikingly odd thing about it is that it was easily and consistently reproducible, and lasted (still lasts?) for weeks. |
I've posted this both in Stack Overflow as well as in the 'issues' of 'dotenv' and have not yet solved it. I don't know that this is a KeystoneJS issue, but it's the last place I know to look. In short: could KeystoneJS be caching my env variables somewhere?
I am working on a KeystoneJS project, currently running in development mode on NodeJS 12.14.0. About a week or ten days ago I noticed that even though I changed some environment variables in
.env
the changes were not reflected at run-time. I've had to actually introduce new variables for the changes to take effect.I've done searches (using WebStorm and VSC) in my code for the old information, but it only appears in my debug logs. That is to say, if the old value of my env var
ANIMAL
was 'rooster' and I've changed it to 'lizard', 'rooster' does not appear anywhere in my code. And yetANIMAL
keeps having the valuerooster
at runtime. So that I have to introduce a new variable,NEW_ANIMAL=lizard
to make any changes work.This does not happen with all env variables -- for instance, I just added a new one,
TEST=1
, ran the app, stopped, changed it toTEST=2
, and the change worked fine. I do not see a pattern in what variables are affected.I'm launching the project through Keystone's launch script, and I'm using TypeScript. My launch script is
"dev": "tsc && cross-env NODE_ENV=development DISABLE_LOGGING=true keystone --entry=tsout/index.js dev --port=4545"
dotenv
is being loaded at the top of the entry point to the project,/index.ts
,which is run each time the project is restarted (for the record, I'm using Babel to be able to use
import
instead ofrequire
throughout the project, but I can't imagine that matters).I just spent half an hour with another dev here going over this and neither of us could figure it out (actually we were trying to track down a weird bug and it turned out it was because even though the
.env
variable had been changed, the app was still reading the old value).If anyone has ever encountered anything like this before -- or has any clues on how to figure it out -- I'd be very grateful.
I include my
package.json
below. I'm running MacOS 10.14.x and NodeJS 12.14.0, for what it's worth.The text was updated successfully, but these errors were encountered: