Fork me on GitHub
#cljs-dev
<
2019-07-08
>
dnolen13:07:30

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

lilactown17:07:42

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

(defn create-element ^react/Element [type props & children]
  ...)
should that type information bubble up the AST and show in the analyzer on the if node? I'm thinking of the machinery that the analyzer uses to do type inference could be re-used, but I haven't had the chance to sit down and try it

lilactown17:07:52

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

dnolen17:07:34

look at the analyzer tests for type inference

dnolen17:07:40

they should give you a sense of what's possible

dnolen17:07:49

also Kevin Lynagh wrote about something like this for hiccup

lilactown17:07:15

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

lilactown18:07:57

awesome! thanks

ghadi19:07:56

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)

ghadi19:07:07

4x... and timed out at 10m

dnolen20:07:44

sounds like an OOM

dnolen20:07:52

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

ghadi20:07:25

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

ghadi20:07:53

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

dnolen20:07:58

our freshness checks are very simple - just last modified

dnolen20:07:08

@ghadi no those are analysis caches

dnolen20:07:15

different purpose

dnolen20:07:35

we can cache compilation of dependencies into a shared directory

dnolen20:07:45

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

dnolen20:07:07

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

ghadi20:07:57

I suspect we're not careful with our deps

ghadi20:07:14

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

ghadi20:07:23

I was surprised source-maps added so much compiile time

dnolen20:07:44

analysis cache is on by default

dnolen20:07:52

source maps shouldn't take much time

dnolen20:07:00

sounds like a memory issue as I alluded to above

ghadi20:07:48

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

dnolen20:07:23

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

ghadi20:07:35

erasing it all

ghadi20:07:53

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

dnolen20:07:05

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

dnolen20:07:12

in general that's not that useful

ghadi20:07:15

no, :simple

dnolen20:07:16

unless you're debuggging

dnolen20:07:05

right still not that useful I would say

dnolen20:07:09

unless you need step debugging

dnolen20:07:25

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

dnolen20:07:43

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

ghadi20:07:45

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

dnolen20:07:49

to create the final one

ghadi20:07:06

{: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"]}]}

ghadi20:07:12

that's the compiler config

dnolen20:07:19

@ghadi really under :simple?

dnolen20:07:24

top level names aren't changed

dnolen20:07:43

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

dnolen20:07:03

(or that's what I recall)

ghadi20:07:09

maybe it's throwing within a minified dep

ghadi20:07:25

I just saw one letter names and assumed...

dnolen20:07:34

right if you have a mangled trace

dnolen20:07:46

it's unlikely to be from ClojureScript under :simple

dnolen20:07:02

top level name do not change under :simple

ghadi20:07:33

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

dnolen20:07:00

@ghadi the step debugger should land in the offending source

dnolen20:07:17

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

dnolen20:07:20

this is w/o sourcemaps