So this is related to a PR I submitted recently, #2366 - I realised that there's a further feature possibly needed - let me know what you think.
I've realised that as well as being able to specify a firebaseProject, it should also be possible to configure it via environment. You might have several deploy configurations, one for development, one for staging, one for production. Although the firebaseProject for production will likely be the same between different environments, the development firebaseProject may differ between different internal teams. This can be problematic because atm, you'd have to change the firebaseProject target in angular.json which is usually checked into version control.
One way I thought about doing it was as follows:
"firebaseProject": "$staging_env" <-- if a $ is detected as the first char, the builder knows that its a shell variable name
- run
dotenvs config() first to read any .env found into process.env.
- use
process.env.staging_env as the firebaseProject.
Although this method seems simple, I'm not overly fond of it because it feels like a hack.
Another way would be to make it an object, like this
"firebaseProject": { "environmentVariable": "$staging_env"}
That seems annoyingly verbose, but a much more robust and clean way of doing it.
So this is related to a PR I submitted recently, #2366 - I realised that there's a further feature possibly needed - let me know what you think.
I've realised that as well as being able to specify a firebaseProject, it should also be possible to configure it via environment. You might have several deploy configurations, one for development, one for staging, one for production. Although the firebaseProject for production will likely be the same between different environments, the development firebaseProject may differ between different internal teams. This can be problematic because atm, you'd have to change the firebaseProject target in angular.json which is usually checked into version control.
One way I thought about doing it was as follows:
"firebaseProject": "$staging_env"<-- if a$is detected as the first char, the builder knows that its a shell variable namedotenvsconfig()first to read any.envfound intoprocess.env.process.env.staging_envas thefirebaseProject.Although this method seems simple, I'm not overly fond of it because it feels like a hack.
Another way would be to make it an object, like this
"firebaseProject": { "environmentVariable": "$staging_env"}That seems annoyingly verbose, but a much more robust and clean way of doing it.