When the dotenv package is installed the new .env features of 9.4.0 don't work: all variables are undefined.
https://github.com/GriffinSauce/next-dotenv-bug
^ Remove dotenv and it will work as expected
Sidenote: regardless of the bug this release kicks ass, great work!
Hey! Thanks for reaching out.
It's the intended behavior that Next.js disables our built-in environment loading when we detect dotenv in your project, as we assume you're handling it yourself.
This was necessary for backwards compatibility!
If you remove dotenv, it should work fine.
Ah that's pretty cool, it would be helpful to document that because right now that's invisible behaviour.
Perhaps even log something like Detected dotenv package - autoloading .env is disabled ?
Great idea! We'll add a warning that we're autodisabling it with a link to learn more.
@Timer sorry to comment on a closed issue, but is there any way to override this behaviour? I use dotenv for a custom alternative build but want to take advantage of the built in .env support in Next 9.4 for my main build.
A similar use case for me too. I'm using dotenv to pass env vars to graphql code generator.
It seems like showing a warning about potential conflicts* when dotenv is present might be more effective.
Edit: *and not disabling it in next
It seems like showing a warning about potential conflicts when dotenv is present might be more effective.
That's already added, see #12744. Warning wouldn't help unfortunately as we'd break existing apps that use dotenv as our loading mechanism is slightly different than what the dotenv.config() package does. Though maybe it's not a problem and we should just enable it.
@timneutkens could you disable it by default when dotenv is detected, but allow a config setting to re-enable it, like an "I understand the risks but I want this anyway" setting?
Problem is that next.config.js needs to have access to the process.env variables too, meaning you can't configure the loading.. as it needs to be loaded before the config is loaded. Hence why we can't "just introduce a setting"
It seems it would be possible to introduce an override in load-env-config with an environment variable (obviously not through dotenv as it wouldn't be loaded at this point). Would you be open to this kind of configuration? I'd really like to use the built in environment config but I still need dotenv for my other workflow so can't use it right now. If you are open to this kind of change, I'm happy to take a crack at it unless you'd rather have the core team handle it.
Adding in env vars for this type of stuff sounds like something that's really not ideal. I'm not opposed to just enabling the built-in dotenv support for everyone tbh because it's not like people are currently configuring anything else to be loaded besides .env.
That'd be great, thanks Tim!
Opened #12911
I have dotenv installed for use with my Jest tests. However, this overrides the default .env bahaviour in my application, which I do not want.
I thought this was fixed? Or am I mistaken?
I'd like to use dotenv manually for Jest and have Next.js do it's own thing for the app.
Most helpful comment
Great idea! We'll add a warning that we're autodisabling it with a link to learn more.