Add Cloudflare Secrets Store binding support

[Cybersoulja]

$(cat <<'EOF'

Summary

• Update AppEnv type to include SecretsStoreSecret in the index signature alongside R2Bucket and Fetcher, enabling full TypeScript support for workers that declare [[secrets_store_secrets]] bindings
• Add commented-out [[secrets_store_secrets]] examples to both template/wrangler.toml and packages/worker/dev/wrangler.toml for user reference
• Extend test bindings (bindings.d.ts, vitest.config.mts) with a mock MY_SECRET binding and add an assertion in server.test.ts verifying secrets are not enumerated as R2 buckets

Test plan

• Run pnpm lint — passes with no errors
• Run pnpm test in packages/worker — server.test.ts confirms MY_SECRET is absent from the buckets list
• Confirm TypeScript compiles without errors (tsc --noEmit) with the updated AppEnv type

https://claude.ai/code/session_018pheiK3TL8nFuSnC9HvpPY
EOF
)

Summary by Sourcery

Add support for Cloudflare Workers Secrets Store bindings and ensure they are correctly typed and excluded from R2 bucket enumeration.

New Features:

• Extend the AppEnv environment type to include SecretsStoreSecret bindings alongside existing bindings.
• Provide commented example [[secrets_store_secrets]] configurations in wrangler.toml templates for users defining Secrets Store bindings.

Tests:

• Add test bindings and integration tests to verify Secrets Store secrets are present in the environment but not treated as R2 buckets.

[gitnotebooks]

Review these changes at https://app.gitnotebooks.com/Cybersoulja/R2-Explorer/pull/4

[sourcery-ai]

Reviewer's Guide

Adds Cloudflare Secrets Store binding support by broadening the AppEnv type to include SecretsStoreSecret, updating wrangler.toml templates with commented secrets_store_secrets examples, wiring a mock Secrets Store binding into the test environment, and asserting that secrets are not treated as R2 buckets, with a changeset to release the update.

Class diagram for updated AppEnv type with SecretsStoreSecret support

classDiagram
    class AppEnv {
        ASSETS : Fetcher
        key_string_map : R2Bucket | SecretsStoreSecret | Fetcher | string
    }

    class R2Bucket {
    }

    class SecretsStoreSecret {
    }

    class Fetcher {
    }

    AppEnv --> R2Bucket : dynamic_bindings
    AppEnv --> SecretsStoreSecret : dynamic_bindings
    AppEnv --> Fetcher : dynamic_bindings

Loading

File-Level Changes

Change	Details	Files
Broaden AppEnv environment typing to support Secrets Store bindings in addition to R2 buckets and other bindings.	Update the AppEnv index signature to accept R2Bucket, SecretsStoreSecret, Fetcher, or string values so workers with secrets_store_secrets bindings are correctly typed. Preserve the explicit ASSETS: Fetcher property while allowing additional typed bindings via the index signature.	packages/worker/src/types.d.ts
Document Secrets Store bindings usage in wrangler configuration templates.	Add a commented example secrets_store_secrets block to the main worker template including binding, secret_name, and store_id placeholders, with a link to Cloudflare docs. Add a commented example secrets_store_secrets block to the dev wrangler.toml used for local development to mirror the main template.	template/wrangler.toml packages/worker/dev/wrangler.toml
Extend the worker test environment to include a mock Secrets Store binding and assert it is not treated as an R2 bucket.	Add MY_SECRET as a SecretsStoreSecret to the Env test type to ensure typings cover the Secrets Store binding in tests. Configure vitest workers bindings to include MY_SECRET as a var-style mock secret value for test runs. Extend the server integration test to assert that MY_SECRET does not appear in the list of discovered R2 buckets, alongside other non-R2 bindings.	packages/worker/tests/bindings.d.ts packages/worker/tests/vitest.config.mts packages/worker/tests/integration/server.test.ts
Record the Secrets Store binding support as a minor version change for r2-explorer.	Add a new changeset documenting that r2-explorer now supports Cloudflare Workers Secrets Store bindings and that AppEnv now includes SecretsStoreSecret, with example configuration added to the template wrangler.toml.	.changeset/add-secrets-store-binding.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[gemini-code-assist]

Code Review

This pull request adds support for Cloudflare Workers Secrets Store bindings, updating the AppEnv type and providing configuration examples. The review suggests including string in the AppEnv index signature to accommodate standard environment variables. Additionally, it recommends enhancing integration tests by verifying that ASSETS are excluded from the bucket list and correcting the MY_SECRET mock to better reflect the runtime behavior of secret bindings.

[gemini-code-assist]

Since ASSETS is also a non-R2 binding (a Fetcher), it should be explicitly verified as excluded from the buckets list to ensure the discovery logic correctly filters out all non-bucket bindings, including the ones explicitly defined in AppEnv.

expect.objectContaining({ name: "NON_R2_BINDING" }),
				expect.objectContaining({ name: "MY_SECRET" }),
				expect.objectContaining({ name: "ASSETS" }),

[gemini-code-assist]

The mock for MY_SECRET uses type: "var", which results in a string at runtime in the test environment. However, a real SecretsStoreSecret binding is an object with a get() method. This discrepancy means the test in server.test.ts is verifying that a string is excluded from the bucket list, but it doesn't guarantee that a real object-based secret binding would be excluded if the discovery logic is not robust enough to distinguish between different object types (e.g., checking for R2-specific methods like list or put).

[sourcery-ai]

Hey - I've left some high level feedback:

• Expanding the AppEnv index signature to R2Bucket | SecretsStoreSecret | Fetcher | string weakens type safety; consider restricting it to the resource-like types you actually iterate over (e.g. R2Bucket | SecretsStoreSecret | Fetcher) and modeling simple string vars separately so that accidental use of non-bucket bindings is caught at compile time.
• Given that AppEnv already declares ASSETS: Fetcher, double-check whether Fetcher really needs to be part of the index signature as well, or if you can narrow the index type to just bucket-like bindings to better reflect how the environment is used in the worker.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Expanding the `AppEnv` index signature to `R2Bucket | SecretsStoreSecret | Fetcher | string` weakens type safety; consider restricting it to the resource-like types you actually iterate over (e.g. `R2Bucket | SecretsStoreSecret | Fetcher`) and modeling simple string vars separately so that accidental use of non-bucket bindings is caught at compile time.
- Given that `AppEnv` already declares `ASSETS: Fetcher`, double-check whether `Fetcher` really needs to be part of the index signature as well, or if you can narrow the index type to just bucket-like bindings to better reflect how the environment is used in the worker.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}