We have a project that generates four different artifact-websites, each of these has to be deployed to a different Firebase project. We could generate a separate firebase.json file for each but I don't think it makes much sense. firebase.json is used to generate an archive that's pushed to Firebase. Why not let us provide everything that's configurable in JSON file via parameters to firebase deploy? This approach plays really well with CI and fully automated deployments of multiple projects at once.
Here's an example - this firebase deploy call is equivalent to having a JSON file.
firebase deploy \
--firebase project-name \
--public ./build
--ignore firebase.json \
--ignore '**/.*'
--ignore '**/node_modules/**'
--token abcd
{
"firebase": "project-name",
"public": "./build",
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
]
}
Well, I discovered the minimum firebase.json file that firebase deploy will require is:
% cat firebase.json
{}
And the deploy command is firebase deploy --project projectname --public . --only hosting.
I think there's more we can do here, but I don't think exposing dozens of command-line parameters is necessarily the way. I'll leave this open while we think.
At the very minimum, don't force the existence of firebase.json if --project and --public are provided.
+1
I felt on this issue while looking for a way to have a slightly different configuration between my firebase deploy (built source code that I'll push in prod) and firebase serve (non built source code that I want to test quickly in my dev environment):
There is probably a way to achieve this (I'm still asking Google about that), but this kinda 'firebase.json overriting' looks interesting to me.
Actually my intuition brung me to firebase help serve thinking that obviously we can do specific stuff directly from the command line, at least for testing purposes.
I think this is a great idea.
@Nowaker in your initial example you use --ignore '**/node_modules/**', but none of the ignores there would be necessary if _build_ is your public folder, right?
I translated the JSON syntax into command line parameter syntax. If it's not necessary in one, it's not necessary in the other.
It's going to be extremely difficult to enumerate the entire array of possible config as command-line options. I'd be more amenable to being able to pass the config JSON inline:
firebase deploy --config '{"hosting":{"public":"dist"}}'
WDYT?
@mbleigh I agree about the entire array enumeration, however if using a JSON string as configuration, it can be painful if we _have to_ specify the full configuration.
Passing JSON that just overrides only the settings it contains, without discarding the actualy configuration file sounds just fine. Discarding the actual configuration file could be maybe optional?
For my own personal sake I only need --public, and nothing else. - I only want to get rid of a file I actually don't need.
However, if I had to specify a lot of configuration, but for different environments, I would prefer specifying the name of a configuration file, .e.g, --config firebase-dev.json.
Or perhaps --config dev, and _dev_ is a property under {"firebase": { "dev": { ... } } in _package.json_.
@Nowaker thanks for your answer, it helped me to make my project up and running upon firebase.
Just a simple correction :
firebase deploy --project projectname --public .
In the above code, we should have use projectId instead of projectname.
so the final line of code for me was something like this:
firebase deploy --project projectId --public .
and of course as you mentioned, we have to create an empty config json "firebase.json" like this as well:
{}
Thanks
@mbleigh While you think about a preferable solution, can you at least not require the existence of config file if the above command line parameters are specified? Thanks.
I would be happy with an ability to specify an alternate config file. When serving locally, I'd like to redirect requests to an HTML file with different API credentials for third-party services.
@ashgeo How does it add anything to this topic?
Internal tracking number: 122551229
Any news on this? Taking the path to an alternative file doesn't seem an incredibly complicated feature and would be much more CI-friendly.
Hello, just to add my own way of dealing with this:
firebase.development.json and firebase.production.jsoncp firebase.development firebase.jsonThis way I can have multiple configs even if it's not officially supported
Most helpful comment
For my own personal sake I only need
--public, and nothing else. - I only want to get rid of a file I actually don't need.However, if I had to specify a lot of configuration, but for different environments, I would prefer specifying the name of a configuration file, .e.g,
--config firebase-dev.json.Or perhaps
--config dev, and _dev_ is a property under{"firebase": { "dev": { ... } }in _package.json_.