Env vars are compiled into app

[mars]

Updated Oct 16, 2016 with the final solution

Problem

When using the REACT_APP_* or NODE_* environment vars to configure the React app, a rebuild (git push heroku master) is required for changes to take effect. These values get embedded in the JavaScript bundle during build, whereas Heroku apps should always read config from environment variables.

Examples of issues this causes:

• when using pipelines, promoting an app (e.g. from staging to production) will not pick-up new values for these variables (until a new build is triggered)
• when setting config vars, the value is not applied immediately; the app must be re-deployed to pick-up the new config value
• in general, slugs are no longer reusable per Heroku's standard architecture

Proposal

Perform replacement of environment variables in the bundle during the app start-up (via .profile.d/ script), so that the current environment variables are used at runtime.

Caveats

• requires developer awareness of the difference between compiled and runtime vars
• requires developer implementation of runtime vars npm module

Try it

Try the proposed runtime env vars strategy by using the buildpack branch:

heroku buildpacks:set https://github.com/mars/create-react-app-buildpack.git#modular-runtime-env-vars

Then, follow the new Runtime vs Compile-time docs.

[eliperelman]

I vote yes. As the person who added the environment variables and a user of Heroku, I can tell you that this is the way I do it as well. If the environment variables change between environments, and these variables need to be embedded in the static app, then the app needs to be re-built for the environment. The other option may be to fetch the Heroku environment, and run npm run build against the cloned environment locally, then deploy that build.

^{For some reason I thought the script was .profile instead of .profile.d.}

[eliperelman]

Also something I have been considering lately is the pain of getting these environment variables into a CRA app in the first place. For example, I've been using the Pixie add-on which exposes a $FIXIE_URL environment variable. It's a pain to have to add a profile script just to map it to REACT_APP_PROXY = $FIXIE_URL, etc.

[mars]

Great to hear from you @eliperelman

.profile.d & .profile are similar in behavior, the docs linked above say:

Scripts in .profile.d/ should only be written by buildpacks. Customers intending to perform application specific initialization tasks at the time a dyno boots should use .profile scripts, which are guaranteed to run after the scripts in profile.d/.

I'm proposing to make this change at the buildpack level, which would not required changes to apps such as individual developers making a .profile script.

Re: pain of non-REACT_APP_* variables… you can attach Heroku Add-ons with a custom prefix to solve this problem:

heroku addons:create fixie --as REACT_APP_FIXIE

See: Creating an add-on

[eliperelman]

Wow, great info, thanks!

[mars]

Try the proposed stateless build strategy by using the buildpack branch:

heroku buildpacks:set https://github.com/mars/create-react-app-buildpack.git#stateless-build

Let me know how it goes 🍃

[mars]

The biggest question remaining is: do folks have builds that take close to or longer than 60-seconds?

[mars]

Just realized, we can use the new release phase feature to perform the build, avoiding boot timeout problems.

Edit: release phase is not a solution, because changes to the slug filesystem are not persisted.

[mars]

I have a new solution which does not suffer from the same build-on-startup issue. Although, it does require adding some code to your React app.

See: runtime-env-vars branch for the technique.

Try it out by setting your buildpack to the branch:

heroku buildpacks:set https://github.com/mars/create-react-app-buildpack.git#runtime-env-vars