[Feature Request] varlock audit: detect cloudflare:workers, IaC bindings, and framework env usage
Maintainer thường phản hồi trong vòng 1 ngày
@theoephraim đang làm issue này rồi.
Từ ngày 1/6/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Description
varlock audit compares keys defined in .env.schema against environment-variable references found in source code. Today it works well for direct process.env.VAR usage and ENV.VAR from varlock/env, but it reports false positives ("unused in schema") for several common deployment patterns — especially Cloudflare Workers deployed via IaC tools other than varlock-wrangler.
In a monorepo using Alchemy for Cloudflare Workers + D1 + Astro:
- Deploy time: secrets and vars are declared as Worker bindings via
alchemy.env.VAR/alchemy.secret.env.VARinalchemy.run.ts. Alchemy reads resolved values fromprocess.env(injected byvarlock run --), but audit does not scan those binding declarations. - Worker runtime: application code reads
env.VARfromcloudflare:workers(sometimes via a thin package re-export). Audit does not trace property access on that import. - Astro marketing site: public vars are consumed via
astro:env/clientimports, notprocess.env.
Running varlock audit from the infra package entry point flags every binding key (e.g. BETTER_AUTH_SECRET, PUBLIC_SERVER_URL, ALCHEMY_PASSWORD) as unused, even though they are actively used.
We currently work around Alchemy-only keys with # @auditIgnore per the audit hint ("If this is used by an external tool…"), but Worker and Astro keys are genuinely referenced in code — audit just cannot see them yet.
Motivation
Accurate varlock audit is important for:
- Solo developers using AI coding agents (detecting drift between schema and code)
- Monorepos where schema lives in
packages/infrabut consumption is spread across apps/packages - Alchemy / better-t-stack adopters who use
varlock run -- <deploy>withoutvarlock-wrangler
Without improved detection, audit either fails noisily or teams blanket @auditIgnore, which defeats the purpose.
Proposed Solution
Extend varlock audit (and/or document first-class patterns) for:
cloudflare:workersenv access — detectenv.VAR, destructuring fromcloudflare:workers, and common re-export wrappers (e.g.@talkiva/env/server).- IaC binding declarations — optional detectors for known patterns such as
alchemy.env.VAR,alchemy.secret.env.VAR, and potentially SST/Pulumi equivalents. - Framework env modules — e.g.
import { VAR } from "astro:env/client"mapped back to schema keys. - Monorepo-aware scanning — when
varlock.loadPathspans multiple packages, default audit scan roots could include sibling app/package directories referenced by the schema entry point.
If full static analysis is out of scope for some patterns, documenting recommended @auditIgnore categories (external CLI tools vs. runtime bindings) would still help.
Alternatives
@auditIgnoreon all binding keys — works today but removes audit coverage for real drift.- Wait for
@varlock/cloudflare-integration+varlock-wrangleronly — does not help Alchemy/SST/Pulumi deploy paths where Worker code still usescloudflare:workerswithout migrating imports tovarlock/env. - Custom audit scripts — possible but duplicates logic Varlock already owns.
Additional Information
- Related runtime binding request (separate concern): #735 — public API to build
__VARLOCK_ENVfor non-wrangler deploy tools. - better-t-stack adoption context: AmanVarshney01/create-better-t-stack#1029 — stacks deploying via Alchemy hit both #735 (runtime redaction) and this audit gap.
- Real-world repro: Alchemy deploy with
varlock run -- alchemy dev; schema atpackages/infra/.env.schemaimportingapps/server/.env.schema; audit run frompackages/infrawith explicit scan paths still reports all binding keys unused.
Example binding declaration audit should recognize:
export const server = await Worker("server", {
bindings: {
BETTER_AUTH_SECRET: alchemy.secret.env.BETTER_AUTH_SECRET!,
CORS_ORIGIN: alchemy.env.CORS_ORIGIN!,
},
});
Example runtime usage audit should recognize:
import { env } from "cloudflare:workers";
// or: import { env } from "@talkiva/env/server";
const origin = env.CORS_ORIGIN;
- Ngôn ngữ chính
- TypeScript
- Star
- 4.9k
- Fork
- 140
- Merge trung bình
- 2 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 35
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của dmno-dev/varlock
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
dmno-dev/varlock#1279 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
dmno-dev/varlock#1100 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 78/100
dmno-dev/varlock#1278 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 72/100
dmno-dev/varlock#1275 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
core:varlock RFC
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 28/100
dmno-dev/varlock#1258 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của dmno-dev/varlock
Issue tương tự
-
Recording drops clicks on links, filters and checkboxes that share a form with a search fieldCó thể đã có người làm @columbia11 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Tencent/BrowserSkill#657 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Choosing a folder while continuing an Antigravity session submits a history fork the runtime rejectsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 87/100
-
ai-handle
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
nextlevelbuilder/dewee-web-v2#138 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
NEARBuilders/citynode.app#512 ·
Maintainer thường phản hồi trong vòng 1 ngày