-
-
Notifications
You must be signed in to change notification settings - Fork 88
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
Using shared variables with no clientPrefix #228
Comments
@julius-retzer If you are working in the server-only environment, the The
This code always assumes that you are in a server environment if the Best if you could provide a repro, easy to check if it's a bug or some configuration mistake🙂 |
I'm also puzzled by this.
I was able to access vars on the client with: export default createEnv({
clientPrefix: "PUBLIC_", // any non-empty prefix, used ONLY to satisfy the library
client: {}, // not a fan of long vars and magic, so I list everything explicitly below
shared: {
NODE_ENV: z.enum(["development", "production", "test"]),
FIRST_VAR: z.any(),
SECOND_VAR: z.any(),
...
}
})
// + pass through to Webpack config in `next.config` file The following does not work: export default createEnv({
clientPrefix: "",
client: {
NODE_ENV: z.enum(["development", "production", "test"]),
FIRST_VAR: z.any(),
SECOND_VAR: z.any(),
...
},
}) with |
It depends on which framework you are working on, but they are mostly the same. Everything that runs on NodeJS/Edge Runtime are consider
The point of having |
When you try to access a variable via |
Thank you for the detailed explanation 🤝 So In NextJS it's pretty easy to prevent bundling like this: // next.config.mjs
...
let {sharedEnv} = await jiti.import("./env.ts")
let withBundleAnalyzer = ...
let nextConfig = withBundleAnalyzer({
...
env: sharedEnv, // a bit simpltified, e.g. NODE_ENV should be dropped
}) so I don't get the purpose of a framework-specific ENV naming. It feels bad to declare the same var as, for example, |
It's mainly because browser doesn't have the concept of ENV in general, that's why frameworks like NextJS, required us to use the Personally, I would just declare |
We have 3+ servers in monorepo, including Python based. But, as a general advice, – you're correct and I agree. |
Hello, thank you for your effort on this nice library.
According to this issue #192, when we don't want to use the client prefix, we should use the
shared
envs. However, even when I do that, I'm gettingAttempted to access a server-side environment variable on the client
when on client.There seems to be this piece of code, which seems to completely prevent using the env variable on client:
Is this a bug or am I doing something wrong?
The text was updated successfully, but these errors were encountered: