Skip to content

js: track document.currentScript instead of hardcoding it to null - #159

Merged
tannevaled merged 1 commit into
mainfrom
js-currentscript-tracking
Sep 9, 2026
Merged

tannevaled merged 1 commit into
mainfrom
js-currentscript-tracking

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

Summary

  • document.currentScript was unconditionally hardcoded to null, so the standard Webpack/Turbopack idiom of reading document.currentScript.src to compute a chunk-loading base path always got an empty result outside a Worker.
  • Found live on tailwindcss.com via a fresh corpus-wide Engine.JSLog sweep: its Turbopack runtime threw Error: chunk path empty but not in a worker for every one of 10 lazily-loaded chunks.
  • Fixed by actually tracking the synchronously-executing <script> node (binder.currentScript), set immediately before and cleared immediately after each execute() call in runScripts — matching the real spec exactly: non-null only for a synchronously-running classic script, null again inside a later timer/callback.
  • A pre-existing test (TestDocumentMisc) had encoded the old always-null behaviour as its own expectation (asserting the running script's own currentScript stringifies to "null"); updated it to check instanceof HTMLScriptElement instead, which is both correct and more informative.
  • Verified live: the real fetched tailwindcss.com page still renders correctly, and a fresh Engine.JSLog sweep shows all 10 "chunk path empty" failures gone with nothing else on any of the ten corpus pages affected.

Test plan

  • TestDocumentCurrentScriptIdentifiesTheRightScriptAndClearsAfterwards added (js/js_test.go) — covers identifying the right script among several, and going back to null inside a timer callback
  • git-stash revert-and-confirm-fail: test fails with the exact predicted TypeError when the source fix is reverted
  • go test ./... green; css/layout/paint/dom/paginate coverage floors re-checked (99.5%/100.0%/100.0%/98.1%/100.0%, unaffected — this fix lives in js, not itself coverage-gated)
  • bench/cmd/compare run against real headless Chrome; tailwindcss.com SSIM essentially flat (0.7053→0.7038, expected — the newly-loading chunks are plausibly lazy/deferred content outside the compared region)

🤖 Generated with Claude Code

document.currentScript was unconditionally null, so the standard
Webpack/Turbopack idiom of reading document.currentScript.src to
compute a chunk-loading base path always got an empty result outside
a Worker. Found live on tailwindcss.com: its Turbopack runtime threw
"chunk path empty but not in a worker" for every one of 10 lazily-
loaded chunks.

Fixed by tracking the synchronously-executing <script> node
(binder.currentScript), set immediately before and cleared
immediately after each execute() call in runScripts -- matching the
real spec exactly, including going back to null inside a later timer
callback.

A pre-existing test had encoded the old always-null behaviour as its
own expectation; updated to check `instanceof HTMLScriptElement`
instead of relying on incidental string output.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@tannevaled
tannevaled merged commit 3a6bcfd into main Sep 9, 2026
7 checks passed
@tannevaled
tannevaled deleted the js-currentscript-tracking branch September 9, 2026 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant