"Env" utility does not support custom variables

[trystendsmyth]

Although a way is provided to define custom variables via script (without the NEXT_PUBLIC prefix), the supported way of accessing those variables throws an error.

To allow for custom variables via script, we must use EnvScript. However, when trying to access those variables using the env function, we get an error. The env function is written to throw an error if the variable does not start with NEXT_PUBLIC_, so the only way to access our variables is with a workaround via window.__ENV, which is not future proof.

Am I interpreting usage incorrectly, or is it possible to get an update to allow better usage of custom variables in the recommended way? Thank you!

[HofmannZ]

@trystendsmyth - Thank you for bringing this to our attention. As you might imagine, we're using the NEXT_PUBLIC_ and did not anticipate this scenario with EnvScript.

On the one hand, we believe guarding for NEXT_PUBLIC_ is a good idea to avoid undefined variables.

On the other hand, we want to provide some flexibility when using this package and env should work when not using the NEXT_PUBLIC_ prefix.

With that in mind, I can see two possible solutions:

1. Add an optional second parameter to the existing env util. Changing the function signature to

function env(key: string, prefixGuard = true): string | undefined

allowing you to bypass the NEXT_PUBLIC_ guard. E.g.:

const API_URL = env('NEXT_PUBLIC_API_URL', false);

2. Introduce a new utility that does not guard for the NEXT_PUBLIC_ prefix. We could name it unguared_env, and you would only have to change your imports:

import { unguared_env as env } from 'next-runtime-env';

We're keen to learn about your thoughts 🙂

[trystendsmyth]

@HofmannZ thank you for responding to my submitted issue. From a usability perspective, it would be consistent for env to be used for both script types, as useEnvContext is used for both provider types.

Based on that, I would potentially suggest option 1.

That said, there is a potential 3rd approach. You're already setting variables on window.__ENV, so you could add an additional variable for the env type of public or custom to check against. Perhaps that would be polluting the global namespace more and adding a parsing dependency, but it would make for a developer experience where the interface isn't changing 🤷‍♂️

Perhaps there's a better 4th approach, but I can't think of it at the moment 😄