Repository navigation
Collapse runtime init into varlock/init and varlock/auto-init - #1239
Conversation
|
Pullfrog stalled The agent stopped emitting events for 125s and was killed by the activity-timeout watchdog. The model produced no output at all before the stall — the request was sent but nothing came back. This is usually transient; re-running often succeeds. Recent agent stderr
|
|
The changes in this PR will be included in the next version bump.
|
📦 Bundle size✅ shrinks the bundle by 7.7 KB (−0.1%)
dist/ only; native binaries are versioned separately and not counted here. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
varlock-website | fddb0da | Commit Preview URL Branch Preview URL |
Oct 29 2026, 06:49 AM |
varlock
@varlock/astro-integration
@varlock/cloudflare-integration
@varlock/nextjs-integration
@varlock/nuxt-integration
@varlock/vite-integration
@varlock/native-helper-darwin
@varlock/native-helper-linux-arm64
@varlock/native-helper-linux-x64
@varlock/native-helper-win32-x64
@varlock/1password-plugin
commit: |
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
Reviewed the supplied incremental delta from 3bfb388b to c334341f, with the full PR diff as context. No previous GitHub reviews or open review threads were present.
- Added OpenNext coverage for encrypted frozen env initialization, app/pages-router rendering, middleware, request-time leak blocking, log redaction, and continued serving in local workerd.
- Registered Framework test execution through the
test:opennextscript and Next.js integration change detection.
Traced the new suite against the shared harness and Next.js fixtures. The OpenNext CI job passed; I did not rerun the suite locally.
gpt-6.1-sol | 𝕏
Adds a single edge-safe init sequence, initVarlockRuntime() from varlock/init (no import side effects), that every init path runs: the new varlock/auto-init entry that calls it on import, the single varlock/init-bundle CJS file the Next.js integration injects into both server and edge runtimes (init-server and init-edge remain as aliases of it), the vite integration's virtual SSR init module, and the Cloudflare init entry. patch-server-response loads node:http and node:zlib lazily and is a no-op where node:http does not exist, so the vite integration no longer needs the ssrEdgeRuntime branch (the option is kept as a deprecated no-op). Node API reads off process are guarded because Next's dev edge sandbox throws on them rather than leaving them undefined. Generated init modules call initVarlockRuntime() rather than importing varlock/auto-init because ESM and bundlers hoist imports above the resolved-env / entry code they have to run after; app entry files use varlock/auto-init for the same reason. A new test evaluates the built dist entries in a node:vm context with no node builtins, and the init bundle under edge-light and Next-dev-sandbox style process shims.
… the tanstack once-only check On the Cloudflare target varlock is bundled into the worker, so the output also contains the initVarlockRuntime() function declaration (unlike the old initVarlockEnv(opts?) one). Match the call form with its semicolon.
Next.js built with @opennextjs/cloudflare and served from local workerd: the build is detected as OpenNext and the env frozen encrypted into the server and middleware handlers, the worker decrypts it from the _VARLOCK_ENV_KEY binding, and the shared Next.js fixtures assert env values on the app page, pages-router SSR and middleware, request-time leak detection, and runtime log redaction on that target.
…Response guard An already-resolved globalThis.__varlockLoadedEnv now wins over an encrypted process.env.__VARLOCK_ENV in initVarlockRuntime, matching initVarlockEnv's precedence, so a blob that would never be read is not decrypted (and a key that is not in process.env is not required). patchGlobalServerResponse skips a ServerResponse whose prototype has no write/end. Docs note that an encrypted blob on a runtime without node:crypto initializes asynchronously.
c334341 to
fddb0da
Compare
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
Reviewed the incremental delta from c334341f to fddb0da9, with the affected initialization paths as context.
- Preserved Resolved-env precedence so an already-loaded graph bypasses decryption of an ignored process-env blob, and added a built-output regression test without a decryption key.
- Guarded Partial HTTP polyfills so
ServerResponsepatching skips prototypes missing callablewriteorendmethods. - Documented Async edge readiness and the need to await
globalThis.__varlockEnvReadyoutside Next.js when Node crypto is unavailable.
The runtime build and 59 focused tests passed. A separate probe confirmed incomplete HTTP polyfills remain unpatched. Framework and deployment suites were not rerun.
gpt-6.1-sol | 𝕏




What
One edge-safe init sequence,
initVarlockRuntime()fromvarlock/init, that every init path runs:varlock/auto-init: new side-effect-on-import ESM entry for apps whose env is already resolved (varlock run, frozen payloads, sandboxes) and have no CLI to call. Documented next toauto-load.varlock/init-bundle: the same sequence as one self-contained CJS file. The Next.js integration injects it into both server and edge runtimes;varlock/init-serverandvarlock/init-edgestay as aliases of it so older integration versions keep resolving.@varlock/cloudflare-integration/initall callinitVarlockRuntime()instead of assembling env init + four patches by hand.varlock/patch-server-responsenow loadsnode:http/node:zliblazily and is a no-op withoutnode:http, which removes the vite plugin'sssrEdgeRuntimebranch (the option is kept as a deprecated no-op; cloudflare, sveltekit and astro callers no longer pass it).Why the vite module calls a function instead of importing
varlock/auto-initESM hoists static imports above the module body, and rollup hoists external imports to the top of a chunk, so a side-effect import would run before the resolved-env blob or the Cloudflare bindings loader the generated module sets up first. Top-level
await import()would fix a single chunk but siblings of an async module evaluate without waiting, so multi-chunk SSR builds could readENVbefore init finished. The same hoisting is why app entry files should useauto-init: an earlier static import is the only thing that runs before sibling imports.Gotcha found by the framework tests
Next's dev edge sandbox
processshim throws when a node API is read off it, rather than leaving it undefined. The old edge bundle never touched those; the unified one does, soprocess.getBuiltinModuleandprocess.stdoutreads are now guarded. A new test evaluates the built dist entries in anode:vmcontext with no node builtins, and the init bundle under edge-light and Next-dev-sandbox style process shims.New framework suite: OpenNext
framework-tests/frameworks/opennextbuilds the Next.js smoke app with@opennextjs/cloudflareand serves it from local workerd (wrangler dev). It asserts the OpenNext build is detected and the env frozen encrypted into the server and middleware handlers, then that the worker decrypts it from the_VARLOCK_ENV_KEYbinding and the app page, pages-router SSR, middleware, request-time leak detection and runtime log redaction all behave as on Node. Registered in the changed-integration detector under the Next.js integration.Verified
varlock, vite, cloudflare, nuxt and nextjs unit suites; docs build; framework tests for vite v7, cloudflare vite7, nuxt v4, Next.js 16 (webpack + turbopack), tanstack-start vite7 and the new OpenNext suite; the real Vercel deployment suite (16/16, plaintext and encrypted frozen env, middleware on the real Edge runtime).
Deferred to the next major (removing the old
patch-*/init-server/init-edgesubpaths and deletingssrEdgeRuntime), since every published integration imports them.