Allow `PUBLIC_*` environment variables in `adapter-node` configuration

[BastiDood]

Describe the problem

The Node.js adapter natively supports special environment variables for configuring the runtime behavior of the Node.js server. Unfortunately, only the non-PUBLIC_*-prefixed versions of these environment variables are supported.

kit/packages/adapter-node/src/env.js

Lines 4 to 17 in 293392b

	const expected = new Set([
	'SOCKET_PATH',
	'HOST',
	'PORT',
	'ORIGIN',
	'XFF_DEPTH',
	'ADDRESS_HEADER',
	'PROTOCOL_HEADER',
	'HOST_HEADER',
	'PORT_HEADER',
	'BODY_SIZE_LIMIT',
	'SHUTDOWN_TIMEOUT',
	'IDLE_TIMEOUT'
	]);

Why would this be useful?

Consider the ORIGIN environment variable, which is the source of truth for the base of the request URL. There are many cases when this ORIGIN would be useful to embed into the page.¹.

Sadly, that can't be done out of the box because ORIGIN is a private environment variable, which requires being executed in a server context. Importing ORIGIN from a component results in a bundle error about leaking private variables to client-side code.²

The correct way to expose this is to use PUBLIC_ORIGIN instead. But again, that doesn't work because adapter-node only checks for ORIGIN.

Describe the proposed solution

The env.js logic in adapter-node should be updated to also consider PUBLIC_*-prefixed environment variables in addition to the envPrefix.

Perhaps an open question would be: how should envPrefix interact with the PUBLIC_* prefix?

I say that the intuitive behavior is to check for both PUBLIC_{envPrefix}_* and {envPrefix}_* variables, but there is an argument to be made for {envPrefix}_PUBLIC_* instead. Personally though, I much prefer the former as it is more consistent with SvelteKit's existing rules on environment variables.

Alternatives considered

I've tried three workarounds for now and only one of them works closest to what I want.

1. Setting envPrefix to PUBLIC. This works, but it exposes all of the adapter-node environment variables. If only PUBLIC_ORIGIN is needed, this is quite overkill.
2. Proxying via the load function in +page.server.js files. This also works, but it falls short when pre-rendering is enabled because it emits a data.json endpoint in the build output. It would certainly be unused as the page is pre-rendered, but I'd rather have it not emit anything at all.
3. Using page.url.origin in client-side code. This has been the best option so far. It still isn't perfect, though, because it now requires JavaScript execution just to obtain the origin at runtime. The pre-rendered output results in http://sveltekit-prerender being the substitute value.³ Ideally, this should be the PUBLIC_ORIGIN itself.

Importance

nice to have

Additional Information

I'd be willing to submit a PR for this if the work is approved by the team. 🚀

Footnotes

1. The data-login_uri for a "sign in with Google" button is my motivating example at work. You can also think about OpenGraph use cases with the <meta> tag. ↩

2. This is great, by the way! 🎉 ↩

3. For OpenGraph use cases in <meta> tags, the origin being pre-rendered as http://sveltekit-prerender is a pre-render-exclusive SEO footgun because some web crawlers can't execute JavaScript. ↩

[elliott-with-the-longest-name-on-github]

I think this is pretty easy to accomplish a few ways:

• Just add PUBLIC_ORIGIN=${ORIGIN} to your .env file. I just tested this and it works great :)
• Set PUBLIC_ORIGIN to ORIGIN during your build/start command (depending on where it matters -- static or dynamic). I just tested `ORIGIN=test PUBLIC_ORIGIN="${ORIGIN}" pnpm build" and it worked fine

Do those cover your use cases?

[BastiDood]

Just add PUBLIC_ORIGIN=${ORIGIN} to your .env file. I just tested this and it works great :)

Yup, this does work with pre-rendering. The downside is that if we only use PUBLIC_ORIGIN, the adapter would not be able to pick up on it at runtime (i.e., via pnpm preview or node build/index.js) because it expects ORIGIN, not PUBLIC_ORIGIN.

Set PUBLIC_ORIGIN to ORIGIN during your build/start command (depending on where it matters -- static or dynamic). I just tested `ORIGIN=test PUBLIC_ORIGIN="${ORIGIN}" pnpm build" and it worked fine

This is a fine workaround that certainly works. Though, duplicating the variables is what I was hoping to avoid because it splits the source of truth into two, which opens the door for accidental misconfiguration.

---

Do those cover your use cases?

Yes, I believe these cover my use cases, but not in a way that I find to be the best developer experience. Ideally, I'd love to pre-render my page with PUBLIC_ORIGIN and also have adapter-node recognize that PUBLIC_ORIGIN is an alias for ORIGIN.

I guess more generally, what I want is first-class adapter-node support for treating PUBLIC_* variables as aliases of their non-prefixed counterparts.

[elliott-with-the-longest-name-on-github]

I guess what I'm saying is it seems fairly trivial to set up your environment in such a way that PUBLIC_ORIGIN is an alias for ORIGIN, which basically closes the door on misconfiguration, since there's only one source of truth. I'm not necessarily against this feature request, though.