Empty NEXT_PUBLIC_* environment variables are evaluated as undefined rather than as empty strings

[bryan-hoang]

Link to the code that reproduces this issue

https://github.com/bryan-hoang/repro-undefined-next-public-env-vars

To Reproduce

1. Run pnpm exec next dev
2. Observe that the website is displaying process.env.NEXT_PUBLIC_FOO: undefined.

Current vs. Expected behavior

I expected process.env.NEXT_PUBLIC_FOO: to be displayed instead, since the .env file contains NEXT_PUBLIC_FOO=. The environment variable is defined as an empty string, but it's not being evaluated as one.

I find it surprising that environment variables that are defined as empty strings be treated as undefined.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #28~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 15 10:51:06 UTC 2
  Available memory (MB): 773973
  Available CPU cores: 48
Binaries:
  Node: 21.7.3
  npm: 10.5.2
  Yarn: N/A
  pnpm: 9.0.4
Relevant Packages:
  next: 14.3.0-canary.13 // Latest available version is detected (14.3.0-canary.13).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Output (export/standalone), Pages Router

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

Additional context

It looks like this issue was first introduced in next@14.2.0-canary-14, as reverting to next@14.2.0-canary-13 fixes the issue.

After looking at the commits between those canary versions, I think the commit that introduced the issue is 76c9496. Specifically, this part of the diff: 76c9496#diff-28c0329619b90836564a7769c43ff473dbd28e8e31b75e650624da4d06911763R68.

Since empty strings are falsey, the environment variable doesn't end up being set.

The same guard against falsey values is present on the current canary version as of writing this.

[timlindsk]

Agreed, this bug silently broke redirection-links for us where we sometimes use different base-paths depending on the environment. I feel like we should be able to expect it to be evaluated as a string when set like one.
NEXT_PUBLIC_BASE_PATH=''

As a temporary fix we reverted to 14.1.4 in wait for a real fix

[icyJoseph]

Nice catch! I've made a PR for it, hopefully it gets reviewed soon

[icyJoseph]

Agreed, this bug silently broke redirection-links for us where we sometimes use different base-paths depending on the environment. I feel like we should be able to expect it to be evaluated as a string when set like one. NEXT_PUBLIC_BASE_PATH=''

As a temporary fix we reverted to 14.1.4 in wait for a real fix

@timlindsk hi, could you show us a small reproduction set of steps, or better yet a repository? I would like to verify that the proposed fix also fixes your issue.

[timlindsk]

It's pretty much an ordinary nextjs setup with NEXT_PUBLIC_BASE_PATH='' in .env, then I'm using it in a utilities function that's returning:
${window.location.origin}${process.env.NEXT_PUBLIC_BASE_PATH}, where it's then called from a function within a page component like: ${appURL()}${path} to create a url. All of which have worked fine before.

Sidenote, separate issue, while troubleshooting: I also stumbled upon an issue where compiling mui/icons-material ended up in a crash because "use strict"; was on top of "use client"; But I have yet to boil down the root of that problem, it seems to be related to a later version of nextjs, but I'm also not sure as what the best practice is regarding it, if they should be switched around by mui/icons-material I mean, or if nextjs should allow for it. Can't seem to find much about it other than the case where there's no "use client"; at all. Any pointer?

[icyJoseph]

It's pretty much an ordinary nextjs setup with NEXT_PUBLIC_BASE_PATH='' in .env, then I'm using it in a utilities function that's returning: ${window.location.origin}${process.env.NEXT_PUBLIC_BASE_PATH}, where it's then called from a function within a page component like: ${appURL()}${path} to create a url. All of which have worked fine before.

Alright, then yea I think this should also cover that.

[macmillan78]

Any progress?

[icyJoseph]

Any progress?

The PR is still open, but no reviews yet

[Lambdac0re]

What a bug... It took half a day to find the issue.

[omerman]

This also happens in App router.. not only Pages router.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.