You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
compiler: resolve bounded module-local helper calls used as Worker URLs #9744
Perry's AOT Worker collector already resolves literals, new URL(..., import.meta.url), ternaries, const locals, and bounded registries. It does not follow a module-local helper that returns one of those already-supported expressions.
Bun standalone bundles commonly wrap an embedded worker URL in a tiny helper. The target is fully static, but Perry warns that the Worker path is not statically resolvable and compiles a runtime throw.
Minimal repro
worker.js:
postMessage("ready");
main.js:
constembeddedWorkerUrl=(path)=>newURL(`file://${path}`);consthooksWorkerUrl=()=>embeddedWorkerUrl("/$bunfs/root/worker.js");constworker=newWorker(hooksWorkerUrl());worker.onmessage=({ data })=>console.log(data);
perry compile main.js --platform bun --bunfs-root . -o app
./app
Today the compile emits the unresolved-Worker warning and that constructor throws if reached.
Acceptance criteria
The Worker path resolver can evaluate a bounded, acyclic chain of module-local functions whose arguments are already-resolved static strings/URLs and whose bodies return a supported path expression.
Both concise arrow bodies and a single return statement are covered.
Parameters are substituted without evaluating arbitrary JavaScript.
The existing candidate-count and recursion/depth caps remain enforced.
Side effects, mutation, recursion, multiple non-static returns, or opaque calls remain unresolved with a precise diagnostic.
The resolved worker module is collected, embedded, and starts in the compiled executable.
Regressions cover both global Worker and node:worker_threads Worker constructors.
Blob/object URLs and genuinely user-supplied runtime paths are outside this issue.
Fixed by #9759, which landed on main via merge train #9798. The train was merged as its own branch, so the Fixes #9744 keyword in #9759 never fired — closing manually. Verified the fix is on main by patch-id (git cherry), not just by the PR being closed.
Activity
proggeramlug commentedon Sep 5, 2026
Fixed by #9759, which landed on
mainvia merge train #9798. The train was merged as its own branch, so theFixes #9744keyword in #9759 never fired — closing manually. Verified the fix is onmainby patch-id (git cherry), not just by the PR being closed.