Skill to migrate functions.config to functions params#20
Skill to migrate functions.config to functions params#20inlined merged 2 commits intofunctions-migrationsfrom
Conversation
| - The `description` attribute SHOULD include tips to help a developer understand how to get the value of the parameter, what it is used for | ||
| and/or tips for usage. Examples may be that the stripe API key can be found in the Stripe dashboard for the environment, that the | ||
| stripe webhook secret should be a test webhook secret in dev environments so that the webhook emulator can be used, etc. | ||
| - The `description` attribute MUST include the name of the `functions.config()` path used prevoiusly, including "functions.config()" so that |
There was a problem hiding this comment.
| - The `description` attribute MUST include the name of the `functions.config()` path used prevoiusly, including "functions.config()" so that | |
| - The `description` attribute MUST include the name of the `functions.config()` path used previously, including "functions.config()" so that |
| ```typescript | ||
| const foo = defineString('FOO', { /* descriptions */ }); | ||
| let myFoo: Foo; | ||
| onInit(() => { |
There was a problem hiding this comment.
All the examples at the bottom use namespaced functions.onInit, but the onInit examples here and elsewhere use the modular import. Want to stick to one, maybe functions.onInit since this guide is for 1st gen?
There was a problem hiding this comment.
Agreed. Do you think I should use functions.params or just the params import since they can be imported at "firebase-functions/v1".params or "firebase-functions/params"
(Will address in next PR in the series)
|
|
||
| ## Context | ||
| The user wants to migrate legacy Cloud Functions code from `functions.config()` (Runtime Config) to the modern `firebase-functions/params` API. | ||
| This is important because Runtime Config is deprecated and will be removed in the future. Runtime Config is also not available in the v2 functions |
There was a problem hiding this comment.
nit: this skill uses "v1"/"v2" terminology, but our docs use "1st gen"/"2nd gen". Given the import path is functions/v1 I'm not sure which is better.
There was a problem hiding this comment.
So, the way I speak specfically/technically is that "v1" and "v2" are SDKs and "1st gen" and "2nd gen" are services.
It currently strictly maps "v1" to "1st gen" and "v2" to "2nd gen" but that does not need to be the case. For example, we've considered making "v1" support "2nd gen" to avoid code rewrites and we've considered making "v2" support "run functions".
Given all that, I think that v1/v2 is appropriate in this document.
|
fyi @egilmorez |
* Adds missing Params support in v1 configurability Requires adding support for new features such as string interpolation (API propsoal oustanding) and value-only transforms (API proposal not outstanding beause the API is not publicly released) * Add fixes for firestore * Remove unnecessary toString method * Format * Add approved spec for secret params metadata. Used in firebase/agent-skills#20. * Changelog
2 participants
This code is NOT COMPLETE and will merge into a feature launch branch.
This is the first of two skills that will be used to help customers migrate from functions.config to functions params. Since N projects may share the same source code, the skill is broken into a code refactoring and a data migration skill. The latter has not been written yet and we should not launch the feature until it is. Additionally, this skill adds descriptions to secrets to help with data migration which is an approved but not launched feature.
Here is a smoke test exmaple of how this skill performed at upgrading the functions-skills repo