Expose env vars globally

[notmd]

A small downside is that we have to use getServerSideProps on every page.

[AbdBarho]

Do you have a rough estimation of how much more additional computation required for the server-side rendering? we don't want CPU usage to sky rocket for some env variables.

[AbdBarho]

could we maybe do it like this?

process.env = new Proxy(env, {
    get(env, key) {
        const value = env[key];
        if (!value) {
           throw new Error("Environment variable not set in _app.tsx")
        }
        return value;
    }
)

I think it is very easy to make this mistake, which is why we should log how to fix it..

I hope nothing else breaks, otherwise just Object.assign(process.env, env)

[AbdBarho]

can you check if this is still needed? I remember that I did some debugging, and this cookie field was always empty.

[notmd]

The req object only available when we use getServerSideProps. So it still works if the page is used with getServerSideProps.

[notmd]

So now we are using mixed getStaticProps and getServerSideProps, it only partially works. I think that's fine

[notmd]

Do you have a rough estimation of how much more additional computation required for the server-side rendering? we don't want CPU usage to sky rocket for some env variables.

Haven't done any benchmarks yet. But I'm running a NextJS app (quite small) that do full SSR, it doesn't use so much CPU. NextJs is really lightweight, SSR only adds extra few milliseconds to the response latency. Let me try to switch page do not use env var to static first.

[notmd]

I managed to use getStaticProps. In my previous implementation, my concern is when the user navigates from static page to ssr page the process.env is not available. But look like next/router will handle all of this (it's still call the server to get the props.).

I also add a warning when we try to access env that is not available (I can't throw an error because the markdown lib also uses env for some special rendering). But this still has some caveats, if we try to access env var "statically" eg: const a = process.env.SOME_THING on a top-level scope of the module, env var won't be able at that time, and the warning is not triggered too. We have to use env var carefully on the client side.