fix(playground): update @marko/run to 0.11.8 so <style> tags compile - #272
Conversation
A `<style>` tag in the playground failed both the browser and the server build with `g.default is not a constructor`, leaving the result pane on BUILD FAILED for any template containing one. marko/translator is CommonJS and reads magic-string through Node's interop, which assumes the require lands on the CommonJS build. Earlier versions of @marko/run pinned resolve.conditions to a list holding both "import" and "require" for production client builds, so the require landed on magic-string's ESM build instead and the extra interop layer left `magic_string.default` bound to the module namespace rather than the class. Both builds threw because the call sits in the `<style>` tag's analyze hook and the playground compiles with source maps enabled. 0.11.8 sets the conditions from a configEnvironment hook and omits both, so Vite appends whichever one matches the importer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UBLTjuSWqH7ok6oNzDbmaT
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
WalkthroughThe pull request updates the 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
PR Preview Deployed (removed)Your changes are live at markojs.com/previews/pr-272. commit 5c43fa9 |
A
<style>tag in the playground failed both the browser and the server build withg.default is not a constructor, so the result pane showed onlyBUILD FAILEDfor any template containing one.Cause
marko/dist/translator/index.js›getStyleImportPath():The translator is CommonJS built with Node-mode interop,
__toESM(require("magic-string"), 1), which unconditionally re-exposesmodule.exportsas.default. That is correct in Node, where magic-string's CommonJS build doesmodule.exports = MagicString.@marko/runbefore 0.11.8 pinnedresolve.conditionsto["browser", "import", "require", "production", "default"]for production client builds. magic-string'sexportsmap listsimportfirst, so with both conditions active therequire()resolved to its ESM build. The namespace then took a second interop wrap:new magic_string.default(...)therefore threw. Both builds failed becausegetStyleImportPathruns from the<style>tag'sanalyzehook rather than a target-specific translate, and the playground compiles withsourceMaps: true, so the call is reached forhtmlanddomalike. Dev was unaffected, since those conditions were build-only.Fix
0.11.8 moves the condition list to a
configEnvironmenthook and leavesimportandrequireout of it, letting Vite append whichever one matches the importer. Therequire()now lands on the CommonJS build the interop expects. Resolved lists are["module","browser","production","default"]for client and["module","node","production","default"]for ssr.No workaround is needed in
vite.config.ts.Verification
/playground.htmlwith a<style>template in headless Chromium: renders with no console errors,css=35B html=47B, matching whatpnpm devproduced all along.brand.htmland a docs page load clean.marko-type-checkpass.Emitted assets total 42,134,764 bytes across 255 files, against 41,949,134 bytes across 258 files on the previous condition list. The condition change re-resolves other dual-published dependencies too, so that ~181 KB difference is expected rather than specific to magic-string.
Follow-up
This removes the trigger, not the underlying fragility. marko's translator is still CommonJS built with Node-mode interop, so it breaks anywhere a bundler resolves that
require()to an ESM file, for instance a webpack or rspackconditionNameslisting both. Worth raising againstmarkoseparately.Generated by Claude Code