Runtime environment variables work by default?

[EranSch]

Hey there, @mars!

First of all, awesome work on this buildpack! This thing works like a dream! Bravo!

I've been working on an internal scaffold that we'll be using this buildpack for and was excited to find your readme notes for Runtime Variables. I set them up and began testing in a review app but then thought to verify the undesired behavior in my existing pipeline.

My example use case is in using a variable such as REACT_APP_API_URL which would be set differently for each stage of the pipeline.

I found the unique Heroku Config Var are already set in the runtime after I promoted the app, before even merging in changes with the @mars/heroku-js-runtime-env package. After noticing this, I'm curious what advantage the functionality in the readme offers over what already happens?

Is the advantage that the new config vars would be available immediately, upon the refresh of a client, even if the bundle files were cached in the browser?

Just hoping to find some clarification. If I didn't say it already, awesome work on this buildpack!

[mars]

So the config vars in each app/stage of the pipeline definitely work as you describe.

The issue is that the npm run build bundling step captures those variables into the webpack bundle. When promoting a release through the pipeline, the build does not run again. Instead the app’s slug is simply passed to the next pipeline stage. That means those bundled values go stale between pipeline stages.

This buildpack’s runtime variables feature instead writes the variables into the bundle as the app launches/starts on each dyno.

Note that using the runtime vars is different than for hardcoded compile/build time; the app accesses runtime through that special js-runtime-env npm module.