Firebase-tools: Akzeptieren Sie die JSON-Datei für Funktionen:config:set

Ich stimme @jpreynat zu , wir fürchten den Tag, an dem wir vergessen, eine Konfigurationsvariable config:set in unsere benutzerdefinierten Bereitstellungsskripts mit einer config.json wäre eine nette Funktion, die hinzugefügt werden sollte.
Gibt es im Moment Workarounds, vielleicht Piping in der Konfiguration?

Scheint, als würden Sie versuchen, die Konfiguration projektübergreifend zu replizieren. Würde firebase functions:config:clone für Sie funktionieren?

Um etwas Kontext zu geben, haben wir uns absichtlich von der dateibasierten Konfiguration abgewendet, da wir der Meinung sind, dass sie schlechte Praktiken fördert (nämlich das Speichern einer Datei voller Geheimnisse, die mit Ihrem Code gespeichert und möglicherweise sogar in Ihr Quell-Repository eingecheckt werden).

Was würden Sie über eine Möglichkeit (Mechanik TBD) denken, um "erforderliche" Konfigurationsvariablen zu deklarieren - und wenn Sie versuchten, im aktuellen Projekt ohne erforderliche Konfiguration bereitzustellen, würde es einen Fehler geben, bevor etwas geändert wurde. Würde das Ihre Hauptanliegen lösen? Wenn nicht, warum ist es für Sie besonders nützlich, eine Datei zu haben?

@mbleigh Genau das wusste ich nicht, dass ich es wollte. Gute Idee!
Wahrscheinlich eine gegebene / was Sie mit "Mechanik TBD" meinten, aber: Definieren der Schlüssel / Konfigurationsstruktur in einer Datei innerhalb unseres Projekts und nicht aus der Ferne, damit sie wie alles andere den git / PR-Überprüfungsprozess durchläuft.
@jpreynat Entschuldigung für das Entführungsproblem

@laurenzlong Danke für den Rat, aber wir versuchen nicht, eine Konfiguration zu duplizieren.
Unser Hauptanliegen ist es, unterschiedliche Projektkonfigurationen abhängig von unserer Bereitstellungsphase zu aktualisieren.
Im Grunde haben wir also eine Konfigurationsdatei pro Umgebung (dev, staging und prod) und legen die Firebase-Konfiguration entsprechend fest (für PRs, Push auf Master und Tags).

@mbleigh Danke für die Informationen.
Wir sind uns jedoch nicht ganz sicher, wie wir all diese envs auf andere Weise als die Verwendung von Konfigurationsdateien speichern können.
Sie sind derzeit zur Vereinfachung des Lesens als JSON formatiert, aber wir überlegen, sie als Schlüssel/Wert-Paare zu formatieren, um sie direkt an den Befehl functions:config:set .
Ich stimme Ihnen zu, dass dies nicht sicherer ist, als eine JSON-Datei zu übergeben.
Haben Sie Empfehlungen, wie wir unsere Umgebungsvariablen für andere Phasen als die Verwendung von Dateien speichern könnten?

@ahaverty Keine Sorge, ich freue mich, dass dies hier diskutiert werden kann.

@jpreynat Wenn Sie functions:config:set ausführen, wird es mit dem aktuellen Projekt gespeichert. Wenn Sie firebase use , um zwischen Projekten zu wechseln, ist Ihre Konfiguration persistent. So können Sie set einmal pro Projekt ausführen und dann ist es immer da. Dies sollte das Problem "unterschiedliche Konfiguration für verschiedene Umgebungen" lösen, also verstehe ich vielleicht das eigentliche Problem nicht?

@jpreynat Ich werde dieses Thema

@laurenzlong @mbleigh Sorry, dass ich auf diesen Thread nicht schnell geantwortet habe .
Wir haben vorerst eine Problemumgehung für dieses Problem gefunden, aber hier ist ein Kontext, um meine Anfrage zu klären:

Wir stellen unsere App mit Travis bereit (beachten Sie, dass dies mit jedem CI oder sogar lokal großartig wäre). Da wir unsere App je nach Branche und Tag in verschiedenen Phasen bereitstellen, wäre es großartig, je nach Umgebung eine andere JSON-Datei verwenden zu können.
Dies würde zum Beispiel erlauben, abhängig von dieser Bedingung entweder firebase config:set -f staging.json oder firebase config:set -f prod.json zu tun.
Unsere Problemumgehung bestand darin, firebase als Knotenmodul zu verwenden, aber wir müssen noch unsere JSON-Konfiguration inline einbinden, die fehleranfällig ist.

Hey @jpreynat Ich bin immer noch etwas verwirrt von deiner Antwort. Sobald Sie die Konfiguration einmal festgelegt haben, bleibt sie immer dort, auch über Bereitstellungen hinweg, es sei denn, Sie heben die Konfigurationswerte explizit auf, indem Sie firebase functions:config :unset ausführen. Es ist also nicht erforderlich, dies als Teil des CI-Prozesses zu haben.

Kann das jemand wieder öffnen? %) @jpreynat @mbleigh Das ist wirklich eines der Dinge, die fehlen. Atm habe ich fast 15 Konfigurationsvariablen (und es kommen noch mehr) und das ist sehr praktisch, wenn functions:config:set JSON in irgendeiner Weise akzeptieren kann.

Großes Votum von uns für den @mbleigh- Vorschlag zum Thema "Erforderliche" Konfigurationsvariablen deklarieren - und wenn Sie versuchten, im aktuellen Projekt ohne erforderliche Konfiguration
Wird auch für uns ein Schmerzpunkt, aber das würde alle unsere Probleme lösen und würde gut in den Versionskontroll- / Überprüfungsprozess passen 👍

https://medium.com/@AllanHasegawa/setting -config-for-firebase-cloud-functions-with-json-136f455e7c69

Hey @yaronyosef Sie können JSON direkt an den Befehl functions:config :set übergeben, es ist nur so, dass Sie es so formatieren müssen, dass es für Ihre Plattform geeignet ist. Für Linux sollte Folgendes funktionieren:

firebase functions:config:set foo='{"bar":"something","faz":"other"}'

Vielen Dank für Ihr Teilen! @laurenzlong
Ich wollte aus einer Datei importieren, also habe ich einen Befehl wie diesen verwendet.

firebase functions:config:set service_account="$(cat service-account.json)"

Ich habe eine Dienstkonto-JSON-Datei in Firebase Cloud Functions importiert, weil ich die Nutzerverwaltungs-API des Firebase Admin SDK verwenden wollte.

Cooler Anwendungsfall! Danke für das Teilen!

Wir würden es auch vorziehen, nicht geheime Konfigurationen über Git zu verfolgen, wo die festgeschriebenen JSON-Laufzeit-Konfigurationsdateien (für mehrere Umgebungen) autorisierend sind und die CI-Umgebung dann functions:config:set aus der Datei anwenden würde, die einer bestimmten Umgebung entspricht (und jede Umgebung entspricht einem separaten Firebase-Projekt).

Wenn Sie Konfigurationen in Git behalten, ist es trivial, sie in Ihre Funktionslaufzeit einzulesen. Setzen Sie sie einfach auf configs/<project_id>.json und dann:

let config = {};
try {
  config = require(`./configs/${process.env.GCLOUD_PROJECT}.json`);
} catch (e) {
  console.log('No config found for project', process.env.GCLOUD_PROJECT);
}

Die von Firebase verwendete Laufzeitkonfiguration wurde speziell entwickelt, um zu vermeiden, dass die Konfiguration in git eingecheckt wird, da wir (insbesondere bei Geheimnissen) festgestellt haben, dass es sich um ein Muster handelt, das mehr Probleme verursacht als es löst.

Das stimmt, allerdings verwenden wir dann die Config-API für diesen Zweck gar nicht mehr. Es kann von Vorteil sein, weiterhin die Config API zum Speichern sensibler Werte zu verwenden (was basierend auf den Firebase-Dokumenten ein geeigneter Anwendungsfall zu sein scheint) und sowohl quellcodegesteuerte als auch nicht verfolgte Werte auf die gleiche genaue Weise zu laden (dh über config() bereitgestellt von firebase-functions ).

Zur Zeit verwende ich den folgenden Einzeiler, um die gesamten .runtimeconfig an functions:config:set zu füttern:

firebase functions:config:set $(jq -r 'to_entries[] | [.key, (.value | tojson)] | join("=")' < .runtimeconfig/${FIREBASE_ENV}.json)

wobei FIREBASE_ENV der Name der Umgebung ist, die bei der Bereitstellung verwendet wird (zB dev ). Es wäre schön, wenn man das noch weiter kürzen könnte, zB

firebase functions:config:set -f .runtimeconfig/${FIREBASE_ENV}.json

Letztendlich ist jedoch auch das möglicherweise nicht erforderlich, wenn die Config-API einfach zu verwendende Audit-Trails aller Änderungen aktiviert (bitte korrigieren Sie mich, wenn dies bereits der Fall ist, ich würde das gerne untersuchen).

Also, wie geht das voran? 😄

Würde gerne sehen, dass der @mbleigh- Vorschlag noch umgesetzt wird! Wir haben ständig Probleme, die Konfigurationen für unsere Nicht-Entwicklungsziele zu vergessen

Danke für den Thread-Bump. Es gibt noch nichts zu berichten, aber ich werde dies in unseren Planungssitzungen noch einmal zur Sprache bringen, um zu sehen, ob wir damit beginnen können, Fortschritte zu erzielen.

Ich validiere meine Konfiguration mit einer JSON-Schemadatei, um sicherzustellen, dass sie alle Werte enthält, die ich erwarte. Diese Validierung ist Teil meiner CI-Pipeline und verhindert die Bereitstellung, wenn sie fehlschlägt. Wenn Sie wie ich TypeScript verwenden, um Ihre Funktionen zu schreiben, können Sie das JSON-Schema aus Ihren Typen generieren.

Es funktioniert hervorragend, mit der Einschränkung, dass die Funktionskonfiguration nur Zeichenfolgen akzeptiert, sodass das Schema nicht überprüfen kann, ob ein Konfigurationswert eine Zahl ist. Für boolesche Werte ist es in Ordnung, weil ich eine Aufzählung mit "true" und "false" als einzige gültige Werte verwenden kann.

Siehe meine CircleCI-Konfiguration und diesen Blogbeitrag als Referenz.

@hgwood danke fürs teilen! Wir werden dies auf jeden Fall auch in unser CI aufnehmen.

Wollte nur meine Lösung für dieses "Problem" und meine Gedanken zur Diskussion hinterlassen:

1. Mir ist bewusst, dass geheime/sensible Werte NICHT im Repo gespeichert werden sollten. Meine Lösung ist nur für nicht geheime Werte. Geheimwerte werden manuell festgelegt, aber eine Möglichkeit, Konfigurationswerte als erforderlich zu markieren, wäre für diese geheimen Werte wunderbar.
2. Ich denke, das ist wichtiger, als manche denken. Es ist eine PITA, einzelne Konfigurationswerte für verschiedene Bereitstellungsumgebungsprojekte manuell festlegen zu müssen und sie nicht gleichzeitig anzeigen/vergleichen zu können. Das Definieren von Konfigurationen in Dateien macht den Prozess viel weniger umständlich.
3. Ich denke, das Hinzufügen eines Funktionskonfigurationseditors zur Webkonsole würde dies erheblich verbessern, aber es wäre wirklich schön, wenn es eine Möglichkeit gäbe, Konfigurationen für mehrere Projekte gleichzeitig anzuzeigen, sodass Sie Konfigurationen für verschiedene Bereitstellungsumgebungen leicht vergleichen könnten.
4. Ich habe schon immer gesagt, dass Firebase die Definition von Umgebungen in einem einzigen Projekt ermöglichen muss, sodass Sie nicht mehrere Projekte als Bereitstellungsumgebungen benötigen. Wenn dies vorhanden wäre, wäre es sehr einfach, Konfigurationen für mehrere Umgebungen in einem einzigen Projekt gleichzeitig anzuzeigen.
5. Meine Lösung hat wahrscheinlich Probleme, traue meinem Code nicht wörtlich, aber ich mag das allgemeine Konzept.

Meine Lösung

Ich verwende kaskadierende YAML-Konfigurationsdateien, was für Standardwerte und Werte nützlich ist, die unabhängig von der Bereitstellungsumgebung für alle Konfigurationen gelten.

./config/default.yml

app:
  name: My App
featureFlags:
  someFeature:
    enabled: false

./config/dev.yml (ähnliche Konfigurationsdateien für andere Bereitstellungsumgebungen)

imports:
  - {resource: default.yml}
app:
  environmentName: Development
services:
  someOtherService:
    baseUrl: https://dev.someotherservice.com/api
featureFlags:
  someFeature:
    enabled: true

Dann habe ich ein kleines Knotenskript geschrieben, das die aufgelöste Konfiguration lädt und eine durch Leerzeichen getrennte Liste von key=val-Paaren zurückgibt

yaml_to_keyval.ts

import * as configYaml from "config-yaml"
import * as flat from "flat"


const yamlFile = process.argv[2]
const config = configYaml(yamlFile)
const flatConfig = flat(config)

const key_val_list = Object.keys(flatConfig).map(function(key){
    return `${key}=${flatConfig[key]}`
})

console.log(key_val_list.join(' '))

Während der CI-Bereitstellung verwende ich dieses Bash-Shell-Skript, um die key=val-Paare abzurufen und sie mit functions:config :set . einzustellen

# env is set to the desired deployment environment (eg "dev"), which is passed as an argument to the CI script command
config_in="$(readlink -f ./config/$env.yml)"
key_vals="$(ts-node ./scripts/node/yaml_to_keyval.ts $config_in)"
firebase functions:config:set $key_vals

@kanemotos Ich mag Ihre cat Lösung, aber ist beim Versuch, Ihre Zertifikatsdatei hochzuladen, kein Precondition check failed Fehler aufgetreten?

Aus diesen Gründen haben wir den Deployment Manager verwendet.

Wir legen die gesamte Konfiguration über "config Yaml" für DM fest. Dann erstellt DM geeignete Laufzeitkonfigurationen und -variablen, und firebase deploy ruft ihre Werte zur Bereitstellungszeit ab und legt sie fest, ohne firebase config:set überhaupt verwenden zu müssen. Dies ermöglicht uns auch, andere Ressourcen (zB Buckets und deren Zugriffskontrolle) einzurichten und deren Werte in RC zu setzen, ohne sie extern an das Template liefern zu müssen. Außerdem können wir dadurch camelCase Konfigurations- und Variablennamen verwenden.

Wir setzen einen Wert nur dann extern, wenn wir einen (verschlüsselten) Dienstkontoschlüssel über die Laufzeitkonfiguration übergeben müssen, da DM Werte nicht sicher verschlüsseln kann. Aber wir verwenden dafür immer noch gcloud beta runtime-config configs variables set (nach der DM-Bereitstellung und vor firebase deploy ) und nicht firebase config:set , da ersteres stdout von KMS akzeptiert.

Ich wollte nur hinzufügen - beim Durchlesen scheint es, dass einige Leute einen entscheidenden Punkt übersehen haben, der zu einiger Verwirrung führt. Es wäre wirklich nützlich, wenn dies auch in der Dokumentation geklärt würde.

Grundsätzlich bleibt das functions.config() zwischen _Deployments_ bestehen, kann aber AUCH zwischen verschiedenen Firebase-Projekten separat gesetzt werden!

Dies bedeutet, dass Sie für Entwicklungs-, Staging- und Produktumgebungen mehrere identische Firebase-Projekte einrichten müssen (anstatt Multi-Site-Hosting zu verwenden oder im GLEICHEN Projekt bereitzustellen ... 👎 ), die jeweils ihre eigenen - unterschiedlichen - Umgebungsvariablen enthalten .

Nachdem Sie Aliase festgelegt haben (oder einfach mit firebase use zwischen Projekten gewechselt haben), können Sie dasselbe Repository in mehreren separaten Firebase-Projekten bereitstellen. So richten Sie eine Entwicklungsumgebung, Staging und Produktion ein - als separate Firebase-Projekte.

Dann können Sie für jede separate Umgebungskonfigurationen wie folgt festlegen:
firebase -P dev config:set - Variablen für Ihre Entwicklungsumgebung setzen
firebase -P prod config:set - Legen Sie Variablen für Ihre Produktionsumgebung fest...

Anschließend können Sie dasselbe Repository wie folgt zweimal bereitstellen:
firebase deploy -P dev
firebase deploy -P prod
und beide werden in ihrem jeweiligen Firebase-Projekt bereitgestellt und enthalten ihre eigene, separate Umgebungskonfiguration, die zwischen den Bereitstellungen bestehen bleibt.

Ja, so machen wir es auch. Separate Projekte für dev/test/prod.

Teilen Sie einfach meine Vanilla-JS-Lösung, die für die Plattform funktioniert, auf der Sie entwickeln (Windows, MacOS, Linux):

Verwenden separater Projekte für dev/test/prod.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

Konfigurationsdateien

JSON-Dateien im /functions/config Ordner:

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/functions/package.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

Wenn noch jemand sucht, gibt es die Methode, die in diesem mittleren Artikel verwendet wird https://medium.com/indielayer/deploying-environment-variables-with-firebase-cloud-functions-680779413484. Hat mir das Leben gerettet.

Was mir persönlich fehlt, ist die Möglichkeit, eine Konfigurationsvariable festzulegen, ohne eine Bereitstellung durchzuführen. Wir haben eine CICD-Pipeline, die die Bereitstellung in unseren verschiedenen Umgebungen durchführt, und wir möchten nicht, dass ein Entwickler den Code lokal erstellt und bereitstellt, insbesondere nicht in der Produktion. So geht die Sache kaputt.

Auch wenn wir eine vorhandene Variable später ändern möchten, während ein Feature entwickelt wird, müssen Sie jetzt das letzte veröffentlichte Tag auschecken, es erstellen, bereitstellen, zurück zu Ihrem Feature-Branch auschecken und fortfahren. Das macht das wirklich unbrauchbar.

Im Wesentlichen möchten wir eine Remote-Konfiguration für Cloud-Funktionen

@bezysoftware Ich denke, Sie müssen Umgebungsvariablen verwenden (anstelle der Umgebungskonfiguration), Sie können den Firebase-Layer überspringen und dies auf der Google Cloud-Plattform tun. https://cloud.google.com/functions/docs/env- an. var

Vielen Dank für Ihr Teilen! @laurenzlong
Ich wollte aus einer Datei importieren, also habe ich einen Befehl wie diesen verwendet.

firebase functions:config:set service_account="$(cat service-account.json)"

Ich habe eine Dienstkonto-JSON-Datei in Firebase Cloud Functions importiert, weil ich die Nutzerverwaltungs-API des Firebase Admin SDK verwenden wollte.

Es hat nicht funktioniert

@Md-Abdul-Halim-Rafi

Firebase- Funktionen:config :set service_account="$(cat service-account.json)"

Hat bei mir funktioniert, ich kann die Konfigurationsvariable mit firebase functions:config:get .
Es hat beim ersten Mal nicht funktioniert, weil ich nicht im Projektordner war und das Firebase-Projekt nicht ausgewählt habe, für das die Konfigurationsvariable festgelegt werden soll. Um das Firebase-Projekt auszuwählen, verwenden Sie firebase use --add , die CLI fordert Sie mit dem auf Liste der Projekte auf Ihrer Firebase-Konsole (vorausgesetzt, Sie sind in der CLI mit firebase login angemeldet)

@dnhyde

Firebase- Funktionen:config :set service_account="$(cat service-account.json)"

Scheint nicht zu funktionieren, wenn Sie in Ihrer Json-Datei andere Werttypen außer Strings verwenden (z. B. boolean oder Zahl):

{
   "test": {
        "hmm": true
    }
}

scheitert mit:

Error: HTTP Error: 400, Invalid value at 'variable.text' (TYPE_STRING), true

Es scheint mir vernünftig, dass ich in der Lage sein sollte, Folgendes zu tun:

firebase functions:config:get > config.json

und dann später:

firebase functions:config:set < config.json

Es macht nur Sinn, dass diese beiden Befehle komplementär sind.

Wenn ich die Konfiguration in einer Datei habe, kann ich sie versionieren und sehen, wie sie sich im Laufe der Zeit geändert hat.

Es ist bedauerlich, dass die einzige Möglichkeit, die wir derzeit haben (mit env=$(cat config.json) ), auch dazu führt, dass meine Fähigkeit, config.json die tatsächlichen Werte zu sein, nicht mehr verfügbar ist, da ich sie nicht in { env: ... } umschließen kann.

Hinweis für mich: Hier muss ich für einen Feature-Pull-Request starten: https://github.com/firebase/firebase-tools/blob/b17611a4ff0d36e157ed06a24f6c81d4e146d9e2/src/functionsConfig.js#L142

Teilen Sie einfach meine Vanilla-JS-Lösung, die für die Plattform funktioniert, auf der Sie entwickeln (Windows, MacOS, Linux):

Verwenden separater Projekte für dev/test/prod.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

Konfigurationsdateien

JSON-Dateien im /functions/config Ordner:

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/functions/package.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

Teilen Sie einfach meine Vanilla-JS-Lösung, die für die Plattform funktioniert, auf der Sie entwickeln (Windows, MacOS, Linux):

Verwenden separater Projekte für dev/test/prod.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

Konfigurationsdateien

JSON-Dateien im /functions/config Ordner:

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/functions/package.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

Entschuldigung, aber wann führen Sie das Skript " config:set :dev" aus? Ich verstehe es nicht... danke!