Fork me on GitHub
#clojurescript
<
2017-04-13
>
devth00:04:58

does :file-min have any affect on advanced compilation?

devth00:04:49

and why do we need to specify :requires if a lib has a dep? does this affect ordering in the compiled src?

thheller08:04:01

@devth :foreign-libs do not go through closure, so no effect on advanced compilation

thheller08:04:31

:requires is for dependency ordering yes but only amongst the foreign libs themselves.

thheller08:04:02

so cljsjs.react.dom is not included before cljsjs.react for example

hlolli08:04:26

@thheller so it means that it makes no sense to add externs to :foreign-libs? I've used :foreign-libs a lot, but always provided externs, just assuming that it's needed.

thheller08:04:06

@hlolli no they are necessary. they are used by closure to prevent renaming of the foreign things you use.

thheller08:04:27

but the source of foreign libs to not go through closure

hlolli08:04:24

@thheller ah ok, so no dead-code elimination I assume, wich makes sense to add :file-min.

thheller08:04:56

@john last time I'll mention this but you are doing things that cannot possibly work in :advanced or even anywhere else really. you cannot just hack the JS side without telling the compiler about it.

thheller08:04:54

but I'm still not sure what you are after so ... just be aware šŸ™‚

devth11:04:42

@thheller thanks. so when you specify :file-min, does it include the min version instead of the file when advanced is on? seems like that would totally mess up externs. trying to debug why js for one lib is completely broken when advanced is on.

devth12:04:40

macbook has frozen up completely requiring hard reboot twice in the last 2 days while running advanced compilation locally šŸ˜Ŗ

thheller12:04:48

@devth neither :file nor :file-min has any impact on what :advanced is doing. only the :externs do. :file or :file-min are just prepended after closure has done its thing.

thheller12:04:15

if the js is broken in :advanced you are most likely missing some externs

thheller12:04:40

try compiling with :pseudo-names true in :advanced to see if you can track down the problem

devth12:04:44

makes sense. i'm not sure if that's the problem at this point

devth12:04:55

pseudo-names didn't have any affect on the runtime error

thheller12:04:09

which error do you see?

devth12:04:11

the externs look right. i've also used inferred externs

devth12:04:36

Uncaught TypeError: Cannot read property 'parentNode' of null

devth12:04:50

basically any invocation of a specific lib will result in runtime errors

devth12:04:53

(the lib is grommet)

devth12:04:31

at findScrollParents (superadmin.js:1969)
    at new Drop (superadmin.js:34714)
    at Menu.componentDidUpdate (superadmin.js:34249)
    at r.notifyAll (superadmin.js:24)
    at r.close (superadmin.js:26)
    at r.closeAll (superadmin.js:27)
    at r.perform (superadmin.js:27)
    at o.perform (superadmin.js:27)
    at o.perform (superadmin.js:27)
    at Object.D [as flushBatchedUpdates] (superadmin.js:27)

thheller12:04:23

compile with :pseudo-names and :pretty-print and :source-maps otherwise this is going to be hard to track down

devth12:04:31

yep i'm using all of those

thheller12:04:43

that trace doesn't look like it?

devth12:04:13

hm. i'll double check. maybe i have a lein profiles merging problem

devth12:04:48

don't think so. looks right

thheller12:04:01

that trace is definitely not from :pseudo-names code

devth12:04:36

if it comes from an external minified foreign lib, i don't know how cljs compiler settings could help

devth12:04:44

the foreign lib is outside its control right?

thheller12:04:04

hmm? so the error isn't in your code?

devth12:04:30

it's in the foreign lib which is called by my code

devth12:04:46

(works under :none optimizations btw)

thheller12:04:12

yes. that is why I'm saying it is most likely externs.

devth12:04:50

hm. i have warn-on-infer on in some files. no way to set that globally i presume.

devth12:04:00

how to determine if externs is missing something?

thheller12:04:46

it wouldn't help you (infer)

devth12:04:02

are there known cases where externs inference doesn't always work?

thheller12:04:30

can you show some code where you are calling into the grommit lib? or the grommet lib calls you?

thheller12:04:12

can you show the full trace?

devth12:04:17

(header #js {:size "medium" :fixed true
               :justify "between" :direction "row"}
          "foo")

devth12:04:35

this calls my wrapper:

(def header
  #?(:cljs (js/React.createFactory (.-Header js/grommet))
     :clj factory-shim))

devth12:04:01

at runtime grommet uses JS to do some fancy positioning stuff that triggers the error

devth12:04:27

Uncaught TypeError: Cannot read property 'parentNode' of null
    at findScrollParents (superadmin.js:1969)
    at new Drop (superadmin.js:34714)
    at Menu.componentDidUpdate (superadmin.js:34249)
    at r.notifyAll (superadmin.js:24)
    at r.close (superadmin.js:26)
    at r.closeAll (superadmin.js:27)
    at r.perform (superadmin.js:27)
    at o.perform (superadmin.js:27)
    at o.perform (superadmin.js:27)
    at Object.D [as flushBatchedUpdates] (superadmin.js:27)
findScrollParents @ superadmin.js:1969
Drop @ superadmin.js:34714
componentDidUpdate @ superadmin.js:34249
notifyAll @ superadmin.js:24
close @ superadmin.js:26
closeAll @ superadmin.js:27
perform @ superadmin.js:27
perform @ superadmin.js:27
perform @ superadmin.js:27
D @ superadmin.js:27
closeAll @ superadmin.js:27
perform @ superadmin.js:27
batchedUpdates @ superadmin.js:26
a @ superadmin.js:27
dispatchEvent @ superadmin.js:26

devth12:04:29

oh that trace is from my usage of menu, not header

thheller12:04:38

I assume you are using cljsjs/grommet?

devth12:04:51

no, i saw that just got added 2 days ago

devth12:04:02

we were using our own foreign lib.

devth12:04:11

next is to try cljsjs' version

thheller12:04:13

which externs are you using?

devth12:04:19

manually generated

devth12:04:26

+ inferred

devth12:04:05

whoa. this one is 18k lines. mine was 588.

thheller12:04:29

you only need externs for the stuff you actually use

thheller12:04:37

so 18k is overkill

devth12:04:57

yeah. i thought mine covered everything but i don't know how to definitively determine that.

devth12:04:12

overkill is better than not enough right? šŸ™‚

thheller12:04:21

overkill can actually hurt you

thheller12:04:52

not important right now

dnolen12:04:35

@devth in the example above so grommet.Header = function() {}; is in your extern file?

dnolen12:04:00

and you're 100% sure your extern file is actually getting loaded?

devth12:04:29

essentially.

var grommet = {
   ...
  Header: function() {}
  ...
}

devth12:04:54

it worked in the past when we were on previous versions. hadn't deployed in a long time (not in prod yet) so things got stale.

devth12:04:09

yeah config looks right

devth12:04:15

:externs ["externs/grommet.externs.js"

thheller12:04:44

how do you include grommet? can you get a non minified one in there?

thheller12:04:53

the trace above is useless

dnolen12:04:56

@devth your externs is wrong

dnolen13:04:18

you canā€™t write externs that way far as I know

dnolen13:04:33

var grommet = {}; gromment.Header = function() {}; ...

dnolen13:04:04

I would examine other externs file like the one for React and follow the conventions very closely

devth13:04:16

@thheller that's the thing, i'm only including the non-minified version at this point.

dnolen13:04:16

you donā€™t need the typing bits but the structure of the code should be exactly the same

dnolen13:04:31

anyhow, nearly positive this is your problem

dnolen13:04:14

I just wouldnā€™t bother

dnolen13:04:17

fix your own externs

thheller13:04:31

yeah do not bother with those

devth13:04:48

ok will try

devth13:04:02

i was thinking of moving to the cljsjs lib anyway though

thheller13:04:16

don't do that, it will just make things harder to debug

devth13:04:28

in general though?

thheller13:04:30

you are saying you are using the non minified version

thheller13:04:38

that trace does not like you are

devth13:04:46

well all my other libs are minified

dnolen13:04:50

@devth in general popular CLJSJS libs are safer since theyā€™ve already worked through these issues

thheller13:04:53

or you really are not on :pseudo-names true

thheller13:04:18

I just want a way to pinpoint the location of your error

thheller13:04:24

right now that is impossible

devth13:04:59

:cache-analysis false
:pretty-print true
:pseudo-names true
:optimizations :advanced
:source-map "resources/public/js/superadmin/superadmin.js.map"
:elide-asserts true
:compiler-stats true
:parallel-build true

devth13:04:02

ok. working on externs

thheller13:04:54

how do you include grommet?

devth13:04:17

:foreign-libs [{:file "resources/public/js/libs/grommet.js"
                ;; :file-min "resources/public/js/libs/grommet.min.js"
                :provides ["grommet"]}

devth13:04:25

(i have file-min commented out right now)

thheller13:04:41

did you rebuild with that?

devth13:04:49

yep. lein clean every time too

thheller13:04:10

take out the foreign lib and just include the /js/libs/grommet.js in your HTML

thheller13:04:28

but keep the externs

devth13:04:22

ah if I don't include it in foreign-libs it can't find the grommet namespace that my wrapper requires: (:require #?(:cljs grommet)

devth13:04:33

any other way to tell it it's defined?

devth13:04:05

actual error is Caused by: clojure.lang.ExceptionInfo: No such namespace: grommet, could not locate grommet.cljs, grommet.cljc, or Closure namespace "grommet" during compile

thheller13:04:42

just don't require it, doesn't matter ..

devth13:04:52

same error when including non-minified grommet directly from html

devth13:04:55

so i'll go fixup externs now

thheller13:04:42

ah .. its the minified react I guess

thheller13:04:50

thats why the trace made no sense šŸ˜›

devth13:04:54

actually the inferred externs look right:

var grommet;
grommet.Paragraph;
grommet.Search;
grommet.DateTime;
grommet.TextInput;
grommet.Select;
grommet.FormField;
grommet.App;
grommet.Footer;
grommet.Button;
grommet.Split;
grommet.Label;
;
grommet.Login;
grommet.Table;
grommet.Heading;
grommet.Header;

devth13:04:08

do i have to tell cljs to use the inferred_externs.js file or does it pick it up automatically?

savelichalex13:04:30

Maybe problem with React.createFactory ?

devth13:04:52

would that manifest only in advanced compile?

thheller13:04:46

what is grommet.js? something you created? can't find it

thheller13:04:55

yes I found that. I mean the actual .js

devth13:04:13

not sure there's an unmified dist version anywhere. we set it up it via npm + webpack

thheller13:04:07

and you ensured that your grommit bundle did not include React?

devth13:04:58

right, that's also managed by webpack

thheller13:04:08

so you don't get React via cljsjs?

devth13:04:21

nope. don't use cljsjs at all right now

thheller13:04:44

I though you might be having two competing React

devth13:04:05

warning: it's 170k lines

devth13:04:48

to confirm i'm not crazy, i just re-built with no optimizations and everything works fine.

thheller13:04:10

something about that trace is still weird

thheller13:04:40

can you check that your compiled superadmin.js does not contain React?

thheller13:04:00

why is it all one line?

devth13:04:14

it's minified

thheller13:04:25

but :pretty-print true

devth13:04:09

wait I think superadmin.js does contain React

devth14:04:34

* React v0.14.3
 *
 * Copyright 2013-2015, Facebook, Inc.
that can't be good

thheller14:04:03

yeah that is bad

thheller14:04:17

no idea why it works in :none but still bad

devth14:04:30

i wonder if some dep has some cljsjs dep. inspecting the dep tree

devth14:04:33

no idea how that got in

rinaldi14:04:25

Would more experienced ClojureScript folks agree with the following statement? >Languages with totally different syntax and semantics, like ClojureScript, are difficult to debug, even when source maps are working perfectly. Source: https://medium.com/@tomdale/glimmer-js-whats-the-deal-with-typescript-f666d1a3aad0

devth14:04:41

devcards dep was in my main :dependencies instead of in the :dev profile šŸ˜«

devth14:04:02

which depends on cljsjs react 0.14.3

rinaldi14:04:20

@thheller Can you elaborate? Was there any pain points with debugging cljs code from your experience?

thheller14:04:26

@rinaldi well the problem above with :externs is sometimes painful

thheller14:04:44

but debugging actual CLJS without externs has not been a problem since source maps

devth14:04:55

confirmed the problem was old version of react being required by devcards šŸ˜« thx for the help @thheller @dnolen

dnolen15:04:27

@rinaldi statement about technology X from people who donā€™t use technology X usually arenā€™t worth serious consideration

dnolen15:04:34

@rinaldi source mapping was the one of most requested early features and adoption skyrocketed after itā€™s implementation

dnolen15:04:56

itā€™s not perfect by any means but it works quite well in my experience, the exception being core.async heavy code

rinaldi17:04:51

You are right. Thank you for the response šŸ‘

darwin15:04:31

source maps work quite well, except for these cases: https://bugs.chromium.org/p/chromium/issues/detail?id=687772

darwin15:04:41

the first (most serious) issue has been fixed just recently

thheller16:04:21

@darwin do you have a reproducible case where source maps dont work properly?

thheller16:04:11

outside of dirac? I'm not quite sure I understand how all that fits together

darwin16:04:37

@thheller all those bugs apply to vanilla devtools

darwin16:04:59

it was just a coincidence that a Dirac user cared to report them

thheller16:04:00

ah ok I see

darwin16:04:03

I donā€™t have a nice repo cases, usually I hit the bugs when doing some other stuff and then tried to debug them in Dirac and discovered those are actually devtools issues

darwin16:04:43

I think devtools devs donā€™t hear about them because those are corner cases exposed by ClojureScript, so not that many people report them

darwin16:04:50

but they are definitely real and devtools devs assigned the bug priority-1 which speaks for itself šŸ™‚

thheller16:04:10

I have one issue where a source map is off by one line nothing too bad but confused me at one point

darwin16:04:47

you could try it in latest dirac, the bugs are fixed there

darwin16:04:00

the problem is that that bug does not make it fail, it just causes wrong source-maps lookups, which is quite confusing

denik16:04:31

is the module-type for :npm-deps in clojurescript 1.9.518 automatically recognized? Having problems with {:monaco-editor "0.8.3"}

thheller16:04:15

@denik the monaco npm package is very weird, it doesn't follow any npm conventions

thheller16:04:52

it probably won't work without a lot of work

denik16:04:56

@thheller šŸ˜ž how did you get it to work?

denik16:04:12

also had problems with foreign libs

thheller16:04:16

use the JS and put it into the page

denik16:04:28

how did you deal with the require?

thheller16:04:02

the monaco package has its own loader system

denik16:04:21

currently I have an ugly require mounting our app in a callback, like

(js/require (array "vs/editor/editor.main")
              #(do
                 (re-frame/clear-subscription-cache!)
                 (r/render [app]
                           (.getElementById js/document "app"))))

thheller16:04:21

basically just followed what they have in their instructions

thheller16:04:00

thats not so bad?

thheller16:04:25

it won't get any better than that probably

thheller16:04:23

@denik there are several open issues on the monaco editor project about AMD/common.js builds

thheller16:04:03

:npm-deps won't help until that happens

darwin17:04:00

@thheller btw. my yesterdayā€™s solution failed due to this assumption: https://github.com/binaryage/cljs-devtools/blob/master/src/lib/devtools/optional.cljs#L11-L12, when cljs-devtools is used as a library via dependencies it does not compile that file

darwin17:04:32

so Iā€™m out of ideas, I cannot use a macro to generate my ns form depending on compiler options, that is not possible because I donā€™t have a way how to import the macro šŸ˜‰

darwin17:04:33

any ideas how I could :require a library depending on compilerā€™s :optimizations settings?

thheller07:04:16

as I said you are trying to solve a problem the user needs to solve IMHO. there is nothing you can do if they decide to include cljs.pprint for example.

thheller07:04:43

I was thinking about adding a warning to :release builds that include certain namespaces

thheller07:04:51

but that is about as far as I would go

darwin13:04:06

thanks, I agree, my solution was an overkill, I ended up just issuing a warning: https://github.com/binaryage/cljs-devtools/releases/tag/v0.9.3

darwin13:04:14

good enough solution

dnolen17:04:25

@darwin probably simpler to just require it but make the ns empty if youā€™re compiling :advanced

darwin17:04:47

@dnolen I need to optionally include cljs.pprint only in non-advanced mode, so I cannot make it empty, I would have to fork it

darwin17:04:54

to wrap the body in some macro

darwin17:04:43

just to clarify: ā€œIā€ as a library donā€™t have control over compiler options or source-paths, I can only observe them in a macro

darwin17:04:00

maybe using two ns forms in a single file? the first one would require the macro and the second one would be generated by the macro, would that work?

dnolen17:04:04

@darwin hrm yeah I donā€™t have a good answer for what you want to accomplish

darwin17:04:37

ok, donā€™t worry, it was an interesting exercise, I will just leave it unresolved

darwin17:04:04

I mean, people should not leave any traces of cljs-devtools in :advanced build, because then it will require cljs.pprint and potentially bloat their optimized build

timgilbert20:04:53

I wonder if something could be defined in the &env macro data (or via a similar approach) for something like detecting :advanced? Thinking about how macrovich works, though it seems mildly hacky

timgilbert21:04:45

Oh, I think I see what the problem is now, yeah. You want to rewrite all references to pprint out of your ns trees under :advanced.

darwin21:04:28

@timgilbert not really rewrite, even if I donā€™t call anything from cljs.pprint, just the fact that I put it into :require in any of my ns-es causes :advanced build to bloat

darwin21:04:46

In cljs-devtools case pprint is nice-to have, so I can dynamically decide to use it, if it is present - that is an easy part, the problem is that I cannot decide to require it or not based on compiler options

timgilbert21:04:21

Gotcha. And a wrapper macro won't help you because the "include pprint" branch will be in the whole ns tree somewhere even if advanced is on

darwin21:04:18

I cannot write (my-macro (ns ā€¦)) because my-macro is not known before the ns-form is processed

timgilbert21:04:45

In Clojure I'd probably use a runtime (require) statement vs an ns form but I'm guessing that's not workable for the cljs compiler?

darwin21:04:59

dunno, I guess @dnolen would suggest it, if it was possible

darwin21:04:51

but Iā€™m pretty ok with this compile-time warning solution at this moment, donā€™t want to spend more time on it, frankly

darwin21:04:28

but it would be nice to have some mechanism to optionally require stuff based on compiler options, now in the light of these DCE issues (they are in cljsā€™s own namespaces like cljs.pprint or even in goog closure library like goog.userAgent)

dviramontes22:04:47

hello all, how does one check for the value null in CLJS ? and I mean js/null not cljs/nil / (lmk if that makes sense)

darwin22:04:22

(nil? value)

dviramontes22:04:52

but that tells you if a value is nil no ? or are null and nil the same thing?

darwin22:04:06

yes, they are the same thing

darwin22:04:15

you can check it in planck for example:

darwin23:04:33

so technically speaking both js/undefined and js/null will be considered as nil values by the nil? predicate

darwin23:04:53

if you did something like this:

darwin23:04:28

that would tell you, that nil in cljs is actually js/null

john23:04:12

Anyone seen it where cljsbuild doesn't produce a goog folder (but produces other) in advanced compilation mode?

john23:04:39

Probably something with my project.clj config

john23:04:26

oh, perhaps it's not supposed to? It's in my worker stub files. disregard.