ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Learn how Haxe’s -dce full flag and custom externs can shrink your JavaScript bundle by removing unused code, with a lodash.debounce example and practical verification steps.
Diagnose and fix ClojureScript advanced‑build ReferenceErrors caused by missing externs, with checks, fixes, and escalation steps.
Learn how to define requirements, create the smallest viable ClojureScript build with :advanced optimizations and externs, enforce trust boundaries, run operational checks, anticipate failure modes, and know when to adjust the design.
I am configuring a ClojureScript build that compiles with :optimizations :advanced via the Google Closure Compiler. The goal is a minified production bundle where calls into a plain JavaScript library — accessed through the js/ prefix and goog.object — still resolve correctly at runtime. The constraint I am unsure about is the externs boundary. My understand
Moving a ClojureScript project from `:optimizations :none` to `:optimizations :advanced` triggers Google Closure Compiler property renaming. The goal is to preserve JavaScript interop property names across that compilation boundary without breaking external references. The uncertainty lies in version-sensitive externs handling: the bundled Closure Compiler v
Migration setup I am migrating a small ClojureScript frontend (a handful of namespaces, Reagent UI) from an older build setup to shadow-cljs, with the goal of zero downtime for users. The dev side is fine: the watch build with :none optimizations recompiles changed namespaces and the page updates without a restart. The failure condition The problem appears o
haxe
clojurescript
javascript