Question for NextJS/JS developers: I had a "it works on my machine" argument with a frontend dev. We were both hired separately, him doing frontend/backend dev and me doing the AWS dev to prod ci/cd stuff. The setup is that once he pushed code, my Github Actions setup will compile the nextjs app, and push it to dev or prod depending on which branch he pushes it to. His nextjs app was unable to read the .env file on the server but the python/fastapi one can. He kept pointing the finger at me so I had to look it up. Apparently, env values are inlined at build time and he didn't know. What the philosophy behind this design? If there's any changes to env file, you'll have to go to the process of rebuilding.

Welcome to the retarded world of react and vercel dick riders

angular dev, but the argument would be that it’s „easier“. We need to deviate from the angular standard (environment.ts) aswell, mainly because we have to dynamically load the „env“ after the deployment. We can also just build the image once. It’s the same for every stage (except prod).

In a perfect would, we’d have a artifact for each deployment target, because there is no „startup env“ stuff to read like in a backend. It’s all just static files.

yeah saw this on gitlsb. I can't generate env variables except with basically a hack. why did they add it eesh. probably just lazy and trying to hide the env? idk

Using the .env file in the frontend basically counts as a preprocessor directive (like constants in C)

There's many reasons for this. First: it's easier; second: it's safer. You don't want some dumb fuck to accidentally include the entire .env file as a dependency and end up showing your db credentials to the world.

But that's something the frontend developer should know, since it's clearly stated from the documentation (and you get to figure that out perfectly fine on your own when you're trying to learn the tools anyway).

I'll elaborate further: if you wanted to have both of these environments aligned without recompilation, you'd have to

- expose your .env to be downloaded on the client side: massive security issue. Cannot overstate how severe would that be

- modify all the code relying on configuration variables: they now come from a server, so you'd need to await everything

- what if you wanted to set your server url in the .env file -which, incidentally, is the first thing you'd want to use it for-? How would the client know the server url to fetch the .env file from? It's on the .env file!

On top of that, the precompilation allows Webpack to recognize unused branches to reduce bundle size (if ALWAYSFALSECUZCOMPILINGFORPROD do THING can be safely removed)

But, then again, all of that is clearly stated in the docs (see: https://webpack.js.org/plugins/...); there's an example literally showing what happens. Your frontend developer should have been aware of that.