Non-built env

[atrauzzi]

Recent environment support is great, although I'm wondering if there could be a way for Gatsby to include an externally provided environment-like configuration at run time that's available early in the bootstrap.

Rationale for this is that once a site is built, the environment data is baked in. If I'm building on a build server and then publishing to an environment in two different steps, I might want to use that same build artifact for all the different environments rather than rebuilding each time.

Examples of the kind of information I'm thinking of are publishable client ids, trusted hostnames and depending on application, tenant/white label parameters.

Only question in my mind is whether something like this belongs in graphql or in a simulated node process.env.

[KyleAMathews]

Either way could work but process.env is the more "normal" way so probably preferable. For GraphQL you can already put data in gatsby-config.js

I might want to use that same build artifact for all the different environments rather than rebuilding each time.

So you want to have all the data for each environment built in?

You could just put this data in a JSON or YAML file and require it in. Then infer the environment by what the hostname is e.g. staging.example.com vs example.com.

[atrauzzi]

No, not quite built in. I want it at run time. So not part of the build. Something that I ship alongside that gets read in by running scripts.

Something like env.json and then the runtime react components can make use of those values just like all the other Gatsby data sources.

That way, my built sites are portable and don't have environment specifics baked in. Which means I wouldn't have to build per environment. Just build once and use a different .json file per environment.

[atrauzzi]

If I can modify that config with things like JSON transforms, etc... Maybe.

[KyleAMathews]

Gatsby is setup with a json-loader. Perhaps just require the env.json file wherever you need it?

[atrauzzi]

Won't that still constitute including it at build time?

[KyleAMathews]

Won't that still constitute including it at build time?

Gatsby is a static site builder ;-)

If you really want to load it completely at run-time, you could just put the env file in the static folder and do an ajax request for it https://www.gatsbyjs.org/docs/adding-images-fonts-files/#using-the-static-folder

Or store the env data somewhere else and load it from there.

[100ideas]

@atrauzzi I needed to get some environment variables into the react frontend at runtime. Couldn't figure out how to insert them into process.env, via gatsby-node.js webpack config, so for now I am calling a simple shell script before every npm start to echo them into a file that is sourced into the app. My package.json:

  "scripts": {
    "prestart": "echo \"GLITCH_URL=$PROJECT_DOMAIN.glitch.me\" > /app/.env.development",
    "start": "npm run prestart && gatsby develop -p $PORT"
  },

In gatsby v1.3.0, the variable definitions in .env.[development|production] are automatically inserted into process.env.

I think the more "gatsby" way of doing it would be to use gatsby-config.js to collect env vars etc. & expose them via a node (maybe a new node type?) in graphql. I might try switching to that.

[atrauzzi]

I understand that the generated site is static, but you still might want some values during early bootstrap to allow for minor variances. The generated site itself would remain unmodified.

If I use ajax requests to accomplish this, I might be too late in the bootstrap for some things?

[KyleAMathews]

@atrauzzi it'd be possible to use ajax to load in environmental variables. You'd be adding those as globals into webpack? You can use https://www.gatsbyjs.org/docs/node-apis/#modifyWebpackConfig for this.

[atrauzzi]

Well, the only question would be, do I have to rebuild the site to update those values with this approach?
Webpack only works on what's available at build time. Imagine I have a completely built site. It's done, the bits are all in place, the HTML files are made, everything is minified:

/site-directory
  ....everything built...
  some.env.json    <- I want this

It's just a small file that gets sourced for environment specific values, but very early on during bootstrap. And it's something I can swap in and out with different values to configure the static site. The trick though is that the environment variables would be loaded at run time, not bundled in.

Would modifyWebpackConfig actually allow for that? Or would it have me calling builds every time I changed the values in some.env.json?

[atrauzzi]

@KyleAMathews - facebook/create-react-app#578 - A similar example in terms of what I'd like to be able to do here. I wonder if it already exists in the ecosystem, Gatsby just needs it put together as a plugin? Maybe a gatsby-browser.js plugin of some kind to get in early during bootstrap, but I'm not sure what the best way to go about it would be from there or what my touchpoints should be.

The gist of it is that bundling environment variables at build time is usually done with the intention of abiding by 12factor conventions. While doing this seems to accomplish the objective, it isn't 100% accurate and might be a bit of a collective misunderstanding. To really get the best out of 12factor, your build artifact should be able to be promoted through the various environments without requiring modification.

---

Digging a little further: https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/utils/webpack.config.js#L47

I'm wondering if this is causing an odd thing inside of my built JS. Seems like everywhere process.env is requested, I end up with a completely new copy of the values, snapshotted at build time. So even if I did want to write a plugin, it can't dynamically add values at run time.

[hervitoDelaVega]

@atrauzzi thank you very much for having raised those interesting questions. Please, may I ask you what did you end up to?

[atrauzzi]

At present I haven't been able to come up with a solution. I think the idea of .env might not be the right way of expressing what I was after -- even though conceptually it's quite similar.

What I want is application configuration, so at that point, I'd just have to make my app responsible for issuing a network request to some well-known path relative to the current page to fetch information.

Hard to say, I think there's still worthwhile thought/discussion on this. But expressing it as "env" may not do the idea justice as env is really more about stuff happening during the webpack & bootstrapping and operation of gatsby.

[hervitoDelaVega]

Thanks @atrauzzi !

[Chuloo]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications we're clearing out old issues as many of them have already been resolved with the latest updates.

This issue is being closed because there hasn't been any activity for at least 60 days. Feel free to open a new one or this one if you'd like to throw in a thing or two 😄 👍