Repository navigation
Feature Request - ng deploy to read firebaseProject from .env vars #2482
Description
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
dotenvsconfig()first to read any.envfound intoprocess.env. - use
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.
Activity
vandres commentedon Jun 1, 2020
Would this already help you?
firebase deploy --project project-devIn my project I am having a npm command like
"deploy:prod": "ng build --prod && firebase deploy --project project"george43g commentedon Jun 6, 2020
Of course, the above method would work, although this is more about consistency and working in teams.
If large teams are working on the same monorepo, they may want to use multiple different development server environments (think building a branch or unreleased version).
Currently, each team or member would have to make their own edits to package.json or angular.json to specify which development env they want to use. If this change was accidentally committed to git, wouldn't be great. Hence the preference for files (
.env) that aren't typically checked into version control (so.gitignore'd).In NRWL NX monorepo, for example, whenever you use
run-commandsbuilder, you are able to specify a.envfile and use variables in your commands, for example:firebase deploy -P $APP_DEV_PROJECT_ID --only functionsand it will read the $VAR from.env.You may be able to achieve something like this with NPM scripts as well, but some may prefer to use the
ng deployfunctionality and keep their deploy setups inangular.jsonorworkspace.jsonwhich uses Angular CLI under the hood.For these reasons, I think it would be beneficial to allow some kind of config to be read that isn't checked into version control, which is usually the
.envfile in the root dir.jamesdaniels commentedon Nov 18, 2020
project is now an option in angular.json for the schematic