-
Notifications
You must be signed in to change notification settings - Fork 925
thomasgauvin: support automatic updates of wrangler.jsonc when creating a new resource in a worker project #9816
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…ng a new resource in a worker project
|
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
wrangler
commit: |
// Generate a unique binding name that doesn't conflict | ||
const bindingName = generateUniqueBindingName(config, resource); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we want to generate the binding name in this way?
Couldn't we just add another interactive question asking the user for what binding name they'd like to use? 🤔
(then check the config file to make sure there isn't a conflict)
Basically what I was thinking was something along the lines of for example:
Would you like to update the wrangler.jsonc file with the new KV Namespace binding? … yes
What binding name would you like to use? MY_KV
Updated wrangler.jsonc with new KV Namespace binding: MY_KV (my-kv, ID: 6d2dd6ae297441688c8376c43e4360d6)
Potentially with an error/or other questions in case there are conflicts
I don't think that just creating the binding with generic names is very polished 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using generic names is what we often have in docs/dashboard, and it's faster, so i wanted to match that. how about I default to generic and allow writing a custom binding?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using generic names is what we often have in docs/dashboard
Yeah, but there (especially in the docs) aren't really dealing with the user specific configs so it does make sense to use a generic naming 🤔
how about I default to generic and allow writing a custom binding?
Sorry what do you mean by allowing writing a custom binding?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PS: to be clear I don't think that using a generic binding name is terrible, I just think that not doing so would provide a better DX for our users
packages/wrangler/src/kv/index.ts
Outdated
@@ -80,6 +80,11 @@ export const kvNamespaceCreateCommand = createCommand({ | |||
type: "boolean", | |||
describe: "Interact with a preview namespace", | |||
}, | |||
"update-config": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again I don't think this feels very polished and I would suggest to have something different, for example a flag config-binding-name
that once set to a string it adds a binding with such name to the wrangler config (+ naming conflict to either error or create a new unique name)
For example:
npx wrangler kv namespace create my-kvvvv3 --config-binding-name MY_KV
Creating namespace with title "my-kv"
Success!
Updated wrangler.jsonc with new KV Namespace binding: MY_KV (my-kv, ID: 3e22ff5cbc63489984343bca4b825fe4)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR 🙂
Code wise I think some things need to be polished also more testing (fixtures) will be needed anyways for now I just left some comments regarding the DX, I don't think it's very polished to just create the bindings names for the user and that we should instead ask the user what names they do want to use instead
Thanks @dario-piotrowicz for the feedback & insights, I've started to address the DX ideas (interactive + config-binding-name) so am converting this to a draft PR for now |
…n, added interactive prompting for binding name
updateJsonConfig(config.configPath!, resource, config); | ||
} else { | ||
// Show snippet only | ||
const envString = args.env ? ` under [env.${args.env}]` : ""; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks unused?
} | ||
} | ||
|
||
export function updateJsonConfig( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add JSDoc to this function?
if (binding.binding && typeof binding.binding === "string") { | ||
if (binding.binding.toUpperCase() === normalizedName) { | ||
return true; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Collapse the 2 conditions?
if (binding.binding && typeof binding.binding === "string" && binding.binding.toUpperCase() === normalizedName) {
return true;
}
I don't think binding.binding
is needed with the typeof?
if (typeof binding.binding === "string" && binding.binding.toUpperCase() === normalizedName) {
return true;
}
|
||
const validation = validateBindingName(config, bindingName); | ||
if (validation.valid) { | ||
isValid = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need isValid
here or can you while(true)
and return bindingName;
here?
*/ | ||
export async function handleResourceBindingAndConfigUpdate( | ||
args: { configBindingName?: string; env?: string }, | ||
config: RawConfig & { configPath?: string }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the calls outside of tests, I see
{ ...config, configPath: config.configPath },
Would it make sense for configPath
to be a distinct parameter?
|
||
// We now have a valid binding name. We can use it to update the wrangler.jsonc config. | ||
if (resource.binding) { | ||
updateJsonConfig(config.configPath!, resource, config); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
config.configPath!
-> should the value be required instead of optional ?
config: RawConfig | ||
) { | ||
// Read the original file content to preserve formatting and comments | ||
const originalContent = readFileSync(configPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: use async version? (also for write)
config.configPath | ||
) | ||
|
||
// Handle binding name and config update using unified utility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love to see code comments and I must say you have done a great job in this PR!
But (nit) this one does not look to add value over the fn name?
// Handle binding name and config update using unified utility |
addresses #9730