Hey guys, I have a random question not related to sst or serverless but github Action. in my github Action.. i have a build step(for react app) this step uses environment variables (Action secrets). I dont want to generate build 3 times, for dev staging and prod. so i am thinking to always generate build with placeholders and use sed to replace the environment variables in the build right before deployment. what could be the possibile drawbacks of doing this. below is a command that i came up with (run this inside the <build folder> which is generated after build)

find . -type f -exec grep -Iq . {} \; -exec sed -i 's/Harshit/harshit/g' {} +

I’m curious to know as well. We were thinking of doing something similar for the

sst.StaticSite

where we replace ie

MY_API_URL

with the deployed endpoint of

sst.Api

Yeah here’s the thread over on the react side about this issue https://github.com/facebook/create-react-app/issues/2353

@Jay, IMO, This tool is more like an alternative/addition to dotenv. And is useful if we are running it as server or local but when we execute build command (generate static assets), we need to find a way to replace the placeholder or the dev env var in the chunk files itself before pushing them to let say s3.

Yeah so the setup people in that thread were saying involves having a single file in the public directory to do the replace. They are trying to avoid doing a replaced in all the chunk files.

Yeah, 😂. I still wanted to try out

sed.

Check out the repo, and try it yourself.

We've had problems with replacing variables after build where the compiler has kindly optimized out the values. But you can usually work around that. (eg.

if (stage === 'prod') { ... }

was kindly removed because

stage

was a constant and it equalled

#{$stage}

. Replacing before compile is time consuming (well because you have to recompile the App!). And then you have a different build between QA and Prod, and ideally you'd want the same build so there isn't chance of something wonky in a different build. (Kinda minor issue though IMO). Runtime configuration is another option, however it means a roundtrip before your app can start (depending how you do it). But you can build this to be pretty optimal, or you can embed it in your index.html or something else. Then you have to write some code to handle reading those values. So you treat the some vars as compile time environment, and other ones as runtime environment. I think as far as

StaticSite

is concerned, a find/replace would be cool. I just currently dump everything in a json file that the frontend expects right before calling

new StaticSite

. With find/replace I could just point it at a template of said file. Optimizers are more of a frontend issue and not really a seed issue I think, so a generic mechanism would be cool.

That’s interesting. Can you share how you using that JSON file in your front end

This is in an angular app

environment.prod.ts

import config from './config-prod.json';

export const environment = {
  production: true,
  apiUrl: config.apiUrl
};