[Feature Request] Public API to build the __VARLOCK_ENV Worker binding for non-wrangler deploy tools (Alchemy/SST/Pulumi)

Aperta
  • Qualcosa non va?
#735 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
backend, devtools

Direzione di ricerca

Read the Cloudflare integration’s init.ts runtime consumer and inspect the existing varlock-wrangler producer to find how it serializes and chunks __VARLOCK_ENV. Define a public way to produce those bindings or document a stable contract, then verify a non-Wrangler deploy tool can supply them to a Worker and the runtime layer still works.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description

Varlock's Cloudflare integration ships an in-worker runtime layer (@varlock/cloudflare-integration/init) that performs console redaction and response leak-detection. It works by reading a __VARLOCK_ENV binding from cloudflare:workers. Today that binding is only produced by varlock-wrangler, which shells out to wrangler. There is currently no public, stable way for a different deploy tool to build that binding.

This request is for a small public API (or a documented stable contract) to construct the __VARLOCK_ENV binding entries, so that non-wrangler deploy tools such as Alchemy, SST, Pulumi, and Terraform can set them as Worker bindings.

Motivation

I deploy Cloudflare Workers with Alchemy rather than wrangler (this is the default on a better-t-stack generated project). varlock run -- <deploy> already gives me fail-fast validation and secret injection with no workaround, because Alchemy reads resolved values from process.env. The one capability I cannot reach is the in-worker runtime layer (console redaction and response leak-detection), because nothing sets __VARLOCK_ENV in the deployed Worker unless I use varlock-wrangler.

The runtime consumer in init.ts is already decoupled from the deploy tool. It only reads __VARLOCK_ENV from cloudflare:workers and does not care how the value got there. Only the producer is coupled to wrangler. Reproducing the producer myself would mean depending on the internal varlock load --format json-full --compact output plus the chunking scheme, which is private and can change without notice.

Proposed Solution

Expose a small public function that returns the binding entries, for example:

import { buildVarlockCloudflareBindings } from '@varlock/cloudflare-integration';

const bindings = await buildVarlockCloudflareBindings();
// => { __VARLOCK_ENV: '...', __VARLOCK_ENV_1: '...', ... }

Any IaC tool could then set these as (secret) Worker bindings. This keeps the chunking and serialization logic owned by Varlock while letting non-wrangler tools opt in.

Alternatively, document the binding name(s), the serialization format, and the chunking rules as a stable public contract.

Alternatives
  • Use varlock-wrangler for the deploy. Rejected for now because it would replace Alchemy as the Worker deploy tool, and Alchemy manages more than the Worker (D1, domains, and the static site) from one place.
  • Reimplement the producer by calling varlock load --format json-full --compact and chunking manually. Rejected because it relies on internal output that is not a public contract.
  • Skip the in-worker layer entirely and rely only on fail-fast validation plus local-dev redaction. This is my current fallback, but it leaves production without runtime redaction and response leak-detection.
Additional Information

Related better-t-stack integration request: AmanVarshney01/create-better-t-stack#1029 (better-t-stack deploys Cloudflare Workers via Alchemy, so this gap affects that integration too).

Environment: solo developer, monorepo, Cloudflare Workers and D1 deployed via Alchemy, Expo mobile app, Astro marketing site.

Lingua principale
TypeScript
Stelle
4.9k
Fork
140
Merge medio
2g 3h
PR unite (30g)
35

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dmno-dev/varlock

Tutte le issue di dmno-dev/varlock

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.