Skip to content
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

Support 'raw' bindings for bindings not directly supported by wrangler #358

Closed
ObsidianMinor opened this issue Feb 1, 2022 · 5 comments
Closed
Labels
enhancement New feature or request

Comments

@ObsidianMinor
Copy link
Contributor

Rather than support every possible binding type (of which there are many, some internal), as a stop-gap we should support specifying an advanced "raw" bindings type that directly converts TOML into JSON as part of the metadata upload for a Worker. This would allow internal developers to use wrangler with bindings that aren't publicly available or are in internal beta.

[raw.internal]
type = "unsafe_internal_binding"
binding_field = "some value"

In the metadata.json, this would look like

{
    "name": "internal",
    "type": "unsafe_internal_binding",
    "binding_field": "some value"
},

It can be used to implement any existing binding as well, but note wrangler can't pick up on them and use them for instance in things like miniflare. As another example however, Service Bindings can be done as:

[raw.my_service]
type = "service"
service = "my_service"
environment = "production"
@ObsidianMinor ObsidianMinor added the enhancement New feature or request label Feb 1, 2022
@Electroid
Copy link
Contributor

This is important for "super secret" bindings that are either in development, or we have no intention of making public (for special internal features). We should do this.

@ObsidianMinor
Copy link
Contributor Author

I can work on this provided we agree on a design.

@threepointone
Copy link
Contributor

This looks great! We should do it with safeguards. Let's discuss on monday after I'm back? In particular, I'd like some warnings logged when someone uses these. I'd also like to understand what the behaviour is for some failure modes (for example, if service bindings were used in this manner but they don't work just yet in wrangler dev)

@Electroid Electroid added this to the 2.1 milestone Feb 3, 2022
@ObsidianMinor
Copy link
Contributor Author

ObsidianMinor commented Feb 7, 2022

For posterity here's the design agreed on:

  • Add an unsafe table, currently with only a bindings sub-table. This can be expanded in the future to support uploading files or appending content to the script metadata of an upload.
  • Keeping the design above, tables added to the bindings table will be appended to the bindings array in a worker upload.
    Example:
[[unsafe.bindings]]
name = "my_binding"
type = "unsafe_binding"
  • These tables are only used during worker upload and edge previews, not during local previews. A warning will appear during local previews explaining this discrepancy.
  • If a binding is written that has the same type as a binding handled by wrangler, a warning will also appear letting the user know that their binding as written isn't supported by wrangler and that they should migrate to a supported format for that binding.
    • For example, once Service Bindings go GA, if a user writes a service binding as
    [[unsafe.bindings]]
    name = "MY_SERVICE"
    type = "service"
    service = "my-service"
    environment = "production"
    They would receive a warning saying something along the lines of
    Raw 'service' bindings are not directly supported by wrangler. Consider migrating to a format for 'service' bindings that is supported by wrangler for optimal support. <insert link to doc>
    
    (wording can be changed)

@threepointone
Copy link
Contributor

Fixed in #411, thank you very much @ObsidianMinor!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants