.env files are problematic because they often end up in version control or left lying on local disks unencrypted, increasing the risk of a secret leak. They're nearly impossible to manage securely at scale, are difficult to distribute across a team, and offer no access control or security.
Need to share a secret value? Use any number of secure communications systems your company has in place. Or generate your own from the system that is issuing secrets. It's not the 1950s, when sharing a secret was considered a national security endeavor. This doesn't need to be rocket science.
You can communicate what's supposed to go in the .env file with a .env.template file, with a list of env variables set equal to an empty string.
I'm glad they at least share the nightmare that is client-side environment variables. Prepare to waste days/weeks of your life sifting through unresolved issues in Next.js repo on GitHub, only to discover that you have to re-architect vast swaths of an application just so a secret (of any kind) is never required on the client. This is incredibly challenging and frustrating to deal with, especially when on a deadline and you're 95% done with a working solution.
In typical Next.js fashion, the official documentation for instrumentation.ts is complete dog crap. It's deceptively short, making the naive developer think it's simple to configure. In reality, you should first read through the 50 open and 71 closed GitHub issues related just to instrumentation (https://github.com/vercel/next.js/issues?q=is%3Aissue%20stat...), and make sure you understand all the undocumented ways in which instrumentation.js will destroy any semblance of productivity or enjoyment of programming.
I'd highly recommend staying away from the dumpster fire that is Next.js. It's too bad it's like the top skill asked for by employers these days, who seem to have no idea what they're signing up for.
latchkey•2h ago
100% uptime, I'm sure.
cowthulhu•39m ago
latchkey•19m ago
duncanfwalker•11m ago
latchkey•8m ago
karmakaze•5m ago