@samgqroberts do you have any bandwidth to help me with this? We talked about it a while ago, and I think you said use webpack to choose which config file we use, right?

@shamshirz the basic idea is that webpack can read any environment variables from bash when you execute it, under the namespace process.env. So commonly one might define build-dev and build-prod npm scripts in the package.json that looked like NODE_ENV=development webpack and NODE_ENV=production webpack. Then, since the webpack.config.js gets executed in a node environment, it can read from the environment like const buildForProduction = process.env.NODE_ENV === 'production'. After that it can alter anything it wants about the output config, notably - whether to minify the JS or provide a sourcemap (usually no sourcemap and minified in production), and potentially whether to have different entrypoints altogether into the source. I don't know if there's a straightforward way to pass arguments to the entrypoints from webpack, which would be a great way to switch the config, but you at least could have different, very thin entrypoints for dev and for prod like background-dev.js and background-prod.js that both grab different config and pass it to the same background.js file.

I think this is a great next step, so let's mergerino once this is ready, but I think we also need to keep in mind that this only allows us to set config at build time, not runtime. The problem I foresee here is that it means when we move around the IP that our server(s) is sitting on, we have to push a new chrome extension build altogether. Maybe that's fine? if we have some static IP that's not liable to change much. I suppose in some service discovery alternative approach there would still need to be a static IP for the thing that tells the chrome extension where to actually connect... ok maybe this is fine. I guess I'd just like to do / see some research in how people do this already