CLJS won't do any checking for you - but sure you can look at the AST and sort that out on your own

I guess my question is, if I tag a return value of a function like:

(defn create-element ^react/Element [type props & children]
  ...)

I suppose I could walk the AST and look for literally react/createElement but that seems brittle

look at the analyzer tests for type inference

they should give you a sense of what's possible

also Kevin Lynagh wrote about something like this for hiccup

I've seen that, but it wasn't obvious to me from the reading (and reading other material on inference) whether that only worked for simple types like string / boolean or if I could add my own opaque types and the engine would also infer that info

it will

awesome! thanks

is the output-dir something that is a good candidate for caching across multiple builds / SHAs in a CI system? I'm seeing more than 3x longer build times with source-maps enabled (simple opts)

4x... and timed out at 10m

sounds like an OOM

@ghadi that aside, along those lines we already supporting caching of dependencies

if I let AWS CodeBuild save and restore the output-dir, will CLJS handle the freshness checking correctly?

(I'm assuming the *.cache.json in the output directory is the caching you're referring to @dnolen)

our freshness checks are very simple - just last modified

@ghadi no those are analysis caches

oh

different purpose

we can cache compilation of dependencies into a shared directory

https://clojurescript.org/reference/compiler-options#aot-cache

it's disabled by default only because a variety of libraries and tooling do yucky stuff with macros

but if you're careful with your deps - it works quite well

I suspect we're not careful with our deps

Does the analysis cache pay off for the current project (not the deps)?

I was surprised source-maps added so much compiile time

analysis cache is on by default

source maps shouldn't take much time

sounds like a memory issue as I alluded to above

@dnolen will bump the memory. The analysis cache is blown away on these build boxes

you're erasing the analysis caches but not the generated JS?

erasing it all

git clone then cljs.main -co script/min.edn -c

and you're generating source maps w/ advanced optimizations?

in general that's not that useful

no, :simple

unless you're debuggging

right still not that useful I would say

unless you need step debugging

we need to merge source maps if you're applying optimizations

we generate one, Closure generates one, and we need to map over them both

yeah we're getting an inscrutable stack trace in a deployed environment

to create the final one

{:main            REDACTED
 :output-to       "resources/public/js/compiled/app.js"
 :output-dir      "resources/public/js/compiled/out"
 :source-map      "resources/public/js/compiled/app.js.map"
 :optimizations   :simple
 :closure-defines {goog.DEBUG false}
 :pretty-print    false
 :externs         ["externs/tribute.js"
                   "externs/keycloak-externs.js"
                   "externs/vega/vega.ext.js"
                   "externs/vega/vega-lite.ext.js"
                   "externs/vega/vega-embed.ext.js"]
 :foreign-libs    [{:file     "resources/public/js/vendor/keycloak/keycloak.js"
                    :provides ["keycloak-js"]}
                   {:file     "resources/public/js/vendor/vega/vega.min.js"
                    :provides ["vega"]}
                   {:file     "resources/public/js/vendor/vega/vega-lite.min.js"
                    :requires ["vega"]
                    :provides ["vega-lite"]}
                   {:file     "resources/public/js/vendor/vega/vega-embed.min.js"
                    :requires ["vega" "vega-lite"]
                    :provides ["vega-embed"]}]}

that's the compiler config

@ghadi really under :simple?

top level names aren't changed

@ghadi :pseudo-names true also works under :simple

(or that's what I recall)

maybe it's throwing within a minified dep

I just saw one letter names and assumed...

right if you have a mangled trace

it's unlikely to be from ClojureScript under :simple

top level name do not change under :simple

ok, thanks. I'll go try to understand what's going on better

@ghadi the step debugger should land in the offending source

just scrolling around will make it clear in what foreign lib you ended up

this is w/o sourcemaps