Fix NODE_ENV TypeScript duplication error in server env template

[Copilot]

Fixes #3188

Note

Coded by Copilot, reviewed by human.

[cloudflare-workers-and-pages]

Deploying wasp-docs-on-main with    Cloudflare Pages

Latest commit:	b10385f
Status:	🚫  Build failed.

View logs

[infomiho]

@copilot you didn't do the equivalent change in the client code

[Copilot]

@copilot you didn't do the equivalent change in the client code

Could you clarify what specific client-side change is needed? I looked at the client env template and it currently uses ensureEnvSchema(import.meta.env, clientEnvSchema) directly without the duplicate property pattern that caused the server-side issue.

The server issue was from { NODE_ENV: defaultValue, ...process.env } but the client side doesn't seem to have this pattern. Are you referring to a specific file or scenario where the client code needs the same destructuring approach?

[cprecioso]

Why don't we declare the default value at the schema level? It seems like it would be a nice place for that. I am not in love with this solution, it's a bit of an inscrutable workaround. (but if it's needed then so be it)

---

At any rate, I think we could do a couple things to improve:

Suggested change

	const { NODE_ENV = serverDevSchema.shape.NODE_ENV.value, ...restEnv } = process.env;
	export const env = ensureEnvSchema(
	{ NODE_ENV: serverDevSchema.shape.NODE_ENV.value, ...process.env },
	{ NODE_ENV, ...restEnv },
	serverEnvSchema,
	)
	const defaultNodeEnv = serverDevSchema.shape.NODE_ENV.value;
	// We manually extract `NODE_ENV` to avoid a TypeScript error about overwriting it blah blah
	const { NODE_ENV: inputNodeEnv, ...restEnv } = process.env;
	export const env = ensureEnvSchema(
	{
	NODE_ENV: inputNodeEnv ?? defaultNodeEnv,
	...restEnv
	},
	serverEnvSchema,
	)

[infomiho]

As we discussed on the call, we'll change as you proposed - but we'll refactor it later on when we upgrade to Zod 4