Is PUBLIC_URL supported for dynamic configuration

[Legion2]

We have multiple react apps which are deployed multiple times with different API and app urls. So we also need to be able to configure PUBLIC_URL which I think is compiled into the files by react. Is this possible runtime-js-env?

[rgalanakis]

The thing that serves your static files needs to write out a change to the actual files- that is, normally things are processed at build time but the runtime-js-env processes them at application boot time. Like, our Dockerfile for a Go application that is both an API server, and serves the frontend files, would have something like this:

WORKDIR /srv
runtime-js-env -i /srv/static/index.html
CMD ["myapp", "server"]

You can take the same pattern for whatever, like modifying the compiled index.html file before nginx starts up.

The changes are still in files written out; this project does NOT modify things in memory. I am not sure of your needs; please give me some more information about what you're doing and I can help more.

Regarding PUBLIC_URL, create-react-app evaluates and renders it at build time (same as other vars). create-react-app also allows you to put it into non-JS places, like index.html. So I'd say:

• If you need a dynamic PUBLIC_URL in JS files, you can just replace it with a different variable name (REACT_APP_DYNAMIC_PUBLIC_URL) and use this project.
• If you need a dynamic PUBLIC_URL in non-JS files, you would need to extend this project or write something yourself. This project just adds a window global with config; it does not try to parse or process all your files, so would be unable to template out something. That is not really a particularly hard problem for one project, but there are so many things that can go wrong for a general use, it needs some care for a library that isn't app-specific.

LMK if you need any more help.

[Legion2]

We currently use nginx in a docker image to serve the static files after they have been compiled in a separate dockerfile stage. We use docker ARG for customizing the images and our pipeline builds multiple images from the same docker file with different arguments. But this process does not scale and is very slow and resource intensive.

We would like to build one docker image and configure it with environment variables on startup. PUBLIC_URL must be customized at startup, just like all other configuration options. It makes no sense to customize PUBLIC_URL in js files but not in the html and other files, because the main point of PUBLIC_URL is that it is used as a self reference in different internal react components. Therefore PUBLIC_URL must always point to the proxy url which serves the current instance of our frontend.

[rgalanakis]

Alright, I think i follow. I'll provide some sample code.

The project that spawned this had sort of a similar situation- we had one Dockerfile building a Go backend that could run for each client; we wanted the backend to serve the compiled create-react-app files; but since CRA doesn't support any runtime configuration, we needed a way to customize the app (client name, etc) at app startup so we didn't need a container or netlify site or whatever per-client.

The Dockerfile for the application looks something like this (it builds the backend, and CRA frontend- in your case you probably don't need the backend build):

ARG ALPINE_VERSION=3.11
ARG GOLANG_VERSION=1.13
ARG NODEJS_VERSION=12.16

FROM golang:${GOLANG_VERSION}-alpine${ALPINE_VERSION} AS lithicapp-builder
RUN apk --no-cache add --update --no-progress make git
COPY . /usr/src/
RUN cd /usr/src/lithicapp && make build

FROM node:${NODEJS_VERSION}-alpine${ALPINE_VERSION} AS lithicapp-frontend-builder
RUN apk --no-cache add --update --no-progress python make g++
COPY . /usr/src/
WORKDIR /usr/src/lithicapp-web
RUN yarn install && yarn build

FROM alpine:${ALPINE_VERSION}
RUN apk --no-cache add --update --no-progress postgresql-client
COPY docker-entrypoint.sh /usr/local/bin/docker-entrypoint.sh
COPY --from=lithicapp-builder /usr/src/lithicapp/lithicappgo /usr/local/bin/lithicappgo
COPY --from=lithicapp-frontend-builder /usr/src/lithicapp-web/build/ /srv/static
WORKDIR /srv
ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["lithicappgo", "server"]

That builds a container that compiles our Go app, our React app, and creates a container that will serve the Go app. The Go app is what serves our React code, rather than nginx. That docker-entrypoint.sh is important. It runs the Go binary which modifies the html. Note that you can run runtime-js-env directly, we use the code as a library because we already have a CLI:

lithicappgo jsenv /srv/static/index.html

All that jenv command does is:

package cmd

import (
	"errors"
	"github.com/lithictech/runtime-js-env/jsenv"
	"github.com/urfave/cli/v2"
)

var jsenvCmd = &cli.Command{
	Name:        "jsenv",
	Description: "Run jsenv on the given file",
	Action: func(c *cli.Context) error {
		index := c.Args().Get(0)
		if index == "" {
			return errors.New("index.html path is required")
		}
		return jsenv.InstallAt(index, jsenv.DefaultConfig)
	},
}

The JS code is set up according to the instructions in this README.

So I think you would want the same thing:

• Build the container, which builds the react app inside it
• Container entrypoint/startup runs js-runtine-env

I just checked and we use PUBLIC_URL in the html and it's fine- we don't use it in the JS but I've never actually used it in the JS.

It's worth mentioning explicitly that runtime-js-env is really two things:

1. a simple HTML manipulator
2. a concept of how to configure your JS/react app.

We don't make too many assumptions about the latter, we just give examples.

So I would try it out and see how it goes.

[Legion2]

So you have something like <link rel="icon" href="%PUBLIC_URL%/favicon.ico" /> in your index.html which gets replaced by runtime-js-env at startup with something like <link rel="icon" href="https://customer1.app.company.com/favicon.ico" /> where PUBLIC_URL is https://customer1.app.company.com?

[rgalanakis]

Not quite- the PUBLIC_URL in index.html is going to be set at build time, I believe to / or whatever you configure (almost never an absolute url).

You could fork runtime-js-env (this would be a thing I'd be happy to upstream) and do something like this:

In index.html, do something like:

<link rel="icon" href="%RUNTIME_JS_ENV_ROOT%/favicon.ico" data-runtimejsenv="" />

And then configure the app to:

• Search for data-runtimejsenv attributes
• Replace %RUNTIME_JS_ENV_ROOT% in the href with some path your env.

This would allow you to do runtime/app-startup templating in static files reliably.

I am though a little confused, going back to your original point. What is the URL/hosting structure you're using where you need to configure PUBLIC_URL per-environment? Usually it's just a path to an internal build/asset folder, as I understand/have seen it.

[Legion2]

Ok I will have a try and replace the absolute url in PUBLIC_URL we currently use with /. Maybe then we don't even have the problem of replacing PUBLIC_URL during server start.