8
msdsk
9d

JESUS FUCKING CHRIST

Working with google shit is a fucking nightmare.
WHY DO THEY HAVE TO REINVENT EVERYTHING ALL OVER AGAIN?
Javascript already have a very standardised way of handling env variables. It's called dotenv. It's simple. It's efficient. But of course google can't have it and must use their own version WITH ENV VARIABLES BEING SETTABLE ONLY THROUGH CLI. Because who would ever want some kind of end user friendliness. That's for the weak, like users of netlify.
Fuck you, google. I wish you could rot in hell.

Comments
  • 8
    Are you running in google cloud?

    If so, then you might not have a normal file system as that would require synchronization over multiple servers.

    In that case, using their existing distributed db is probably easier than building a virtual file system just to support a node js module.
  • 0
    @Voxera

    This though creates a pretty annoying disconnection between dev environment and production one. With netlify I'm also working with a cloud and yet, as the end user, I don't need to care about it, because their solution replicates the standard - I set up env variables from their web app and inside my code read from process.env
  • 0
    Just run this command before firebase serve when working locally

    firebase functions:config:get > .runtimeconfig.json
  • 1
    @msdsk well, easier for google ;)

    But yes, it makes for a challenge in being able to test.
  • 1
    You are not the end user, you know that?
  • 1
    Yep. Had that same conversation with an admin at work the other day:

    A: "Can you not just make the arguments parameters for shell script?"
    Me: "It is, just pass and environment file?"
    A: "Yes yes, but can you make to where I can pass individual envvar?"
    Me: "No :). If you want to modify it to do so, it's in git. Make the change, modify all the things that depend on it, run a full regression test and submit a PR I can decline."
    A: "ah ok, sure sure, yes I will do"
Add Comment