Fork me on GitHub
#shadow-cljs
<
2017-11-27
>
mjmeintjes03:11:39

Hi. I've been using shadow-cljs for a new project, and it seems to be working well. However, I've run into a wall trying to get spec-tools library added a a dependency. When I start up shadow-cljs with spec-tools added as a dependency, I get the following error:

failed to inspect cljs file: jar:file:/home/matthys/.m2/repository/metosin/spec-tools/0.5.1/spec-tools-0.5.1.jar!/spec_tools/core.cljc {:tag :shadow.build.classpath/inspect-cljs, :resource-name "spec_tools/core.cljc", :url #object[java.net.URL 0x7f2d31af "jar:file:/home/matthys/.m2/repository/metosin/spec-tools/0.5.1/spec-tools-0.5.1.jar!/spec_tools/core.cljc"]}
Has anyone seen a similar error before?

mjmeintjes03:11:34

This is then followed by the following exception:

failed to parse ns form {:clojure.spec.alpha/problems ({:path [:clauses :refer-clojure :clause], :pred #{:refer-clojure}

thheller09:11:41

@mjmeintjes fixed in [email protected]. my ns parser was a bit too strict and didn’t allow (:import) which spec-tools.impl has for :cljs

mitchelkuijpers15:11:28

Is this supported in shadow-cljs: js/document.body to get the document body? Because I am trying to use a preload for fulcro-devtools and here: https://github.com/fulcrologic/fulcro-inspect/blob/develop/src/fulcro/inspect/ui/events.cljs#L79 target is undefined

colindresj15:11:43

@thheller Should i be using package.json or :npm-deps for listing and managing js dependencies?

colindresj15:11:19

I’ve been using package.json, but recently noticed that if I require CLJS-lib A (built with shadow) that uses package.json for js deps within CLJS-lib B (also shadow-built), I won’t get CLJS-lib A’s js dependencies

thheller17:11:04

@mitchelkuijpers yes of course thats supported.

thheller17:11:11

@colindresj libraries should declare :npm-deps in a deps.cljs file that will make shadow-cljs isntall them on startup

colindresj17:11:55

Thanks @thheller. So, sort of like foreign libs were specified, except obviously replacing :foreign-libs for :npm-deps

colindresj17:11:22

What’s the mapping look like within :npm-deps? is it module name to semnatic versioning range?

thheller17:11:40

{:npm-deps {"thing" "range}} yes

colindresj17:11:46

Cool thank you

tiensonqin17:11:35

@thheller I have some problem with js/requestAnimationFrame. I check the output of (or batched-updates js/requestAnimationFrame), it's

return or__32840__auto__;
} else {
  requestAnimationFrame;
}

tiensonqin17:11:36

figwheel outputs:

if(cljs.core.truth_(or__30096__auto__)){
return or__30096__auto__;
} else {
return requestAnimationFrame;
}

tiensonqin17:11:29

If I changed the output of shadow-cljs to figwheel output, then it doesn't complain.

tiensonqin17:11:01

The error is something like: Uncaught TypeError: Cannot read property 'cljs$core$IFn$_invoke$arity$1' of undefined at Object.citrus$reconciler$schedule_update_BANG_ [as schedule_update_BANG_]

thheller17:11:28

hmm what the heck

thheller17:11:32

it is indeed undefined

thheller17:11:16

var G__54995_54997 = "or";
var G__54996_54998 = (function (){var or__34403__auto__ = null;
if(cljs.core.truth_(or__34403__auto__)){
return or__34403__auto__;
} else {
document.body}
})();
console.log(G__54995_54997,G__54996_54998);

thheller17:11:23

thats missing a return

tiensonqin17:11:33

yeah exactly!

thheller18:11:10

looking into that, not a clue what could cause this though

tiensonqin18:11:49

Currently I can work around it by wrapping a function: (or batched-updates (fn [] js/requestAnimationFrame))

tiensonqin18:11:10

which works for me.

thheller18:11:14

ah crap found it …

thheller18:11:17

I really need to start writing tests for the compiler hacks I’m doing

thheller18:11:25

this is not cool 😞

tiensonqin18:11:27

Thank you very much for your great effort!

tiensonqin18:11:42

I'll try it soon and report back.

tiensonqin18:11:35

@thheller confirmed it works, thanks.

sundbp21:11:48

I’m running into this when trying to run shadow-cljs check foo:

sundbp21:11:50

-> Closure - Checking ...
ClassCastException: clojure.lang.PersistentVector cannot be cast to java.lang.String
	shadow.build.closure/closure-source-file (closure.clj:565)
	shadow.build.closure/closure-source-file (closure.clj:565)
	shadow.build.closure/source-map-sources/fn--21021 (closure.clj:930)

sundbp21:11:05

any tips on what’s going on? @thheller

sundbp21:11:22

wanting to run it to find a problem with the aero lib on nodejs, in advanced opt mode it gives:

sundbp21:11:24

function jB(a,b,c){b=b.l?b.l():b.call(null);$f.c(c,Qd,a);return b}function kB(a,b,c){b=null!=b&&(b.o&64||p===)?pf(ni,b):b;var d=E.b(b,Sk),e=E.b(b,Ck),f=E.b(b,Nk);if(v(Zl.a(f)))return null;try{var g=jB(a,d,c)}catch(k){throw c=k,[x.a(["could not start [",x.a(a),"] due to"].join(""))," ",x.a(c)].join("");}hB(b,g);$f.D(fB,T,a,new u(null,1,[Ck,e],null));return iB(new X(null,2,5,Y,[a,Nk],null),new vi(null,new u(null,1,[Zl,null],null),null))}
                                                                                                                                                                                                                             ^
could not start [#'permafrost.config/config] due to TypeError: Cannot read property 'b' of undefined

sundbp21:11:29

but is fine in :simple mode.

thheller21:11:45

yeah I broke check recently when doing the externs inference work

thheller21:11:58

try shadow-cljs release app --debug

sundbp21:11:12

k, running. tks

thheller21:11:23

compiles with source-maps and pseudo-names to debug those kind of things

thheller21:11:54

check isn’t totally reliable anymore due to all the new JS interop

sundbp21:11:33

-> Closure - Optimizing ...
ClassCastException: clojure.lang.PersistentVector cannot be cast to java.lang.String
	shadow.build.closure/closure-source-file (closure.clj:565)
	shadow.build.closure/closure-source-file (closure.clj:565)
	shadow.build.closure/source-map-sources/fn--21022 (closure.clj:930)

sundbp21:11:55

so still trips up source-maps..

thheller21:11:19

which :target is that?

sundbp21:11:41

:builds
 {:pf {:target :node-library
       :output-to "out/permafrost.js"
       :exports {:main permafrost.cli/main}
       :devtools {:before-load permafrost.cli/stop!
                  :after-load permafrost.cli/start!}
       :release {:output-to "permafrost.js"
                 :compiler-options {:infer-externs :auto
                                    :optimizations :advanced}}}}}

sundbp21:11:53

and running shadow-cljs release pf --debug

sundbp21:11:24

I’ve narrowed it down to be in the aero library (i.e. if i exclude the aero/read-config call doesn’t trigger). but was hoping for a bit more info to figure out where it is.

thheller21:11:15

whats aero?

thheller21:11:18

ClassCastException: clojure.lang.PersistentVector cannot be cast to java.lang.String should be fixed in [email protected]

sundbp21:11:57

giving it a try

thheller21:11:26

not sure what aero has to do with it though. release source maps were just generally broken for :node-library

sundbp21:11:53

yeah - i’m just hoping that i’ll get a bit more info out with that fix, letting me find the issue in aero

thheller21:11:12

(fs.readFileSync source "utf-8") probably this

thheller21:11:36

or (os.hostname)

sundbp21:11:19

/Users/sundbp/dev/bi/permafrost/permafrost.js:20075
    throw $done$jscomp$9_t__38328__auto__$jscomp$inline_1326$$ = $e38700$jscomp$inline_1327$$, [$cljs$core$str$$.$cljs$core$IFn$_invoke$arity$1$(["could not start [", $cljs$core$str$$.$cljs$core$IFn$_invoke$arity$1$($state$jscomp$22$$), "] due to"].join("")), " ", $cljs$core$str$$.$cljs$core$IFn$_invoke$arity$1$($done$jscomp$9_t__38328__auto__$jscomp$inline_1326$$)].join("");
    ^
could not start [#'permafrost.config/config] due to TypeError: Cannot read property '$cljs$core$IFn$_invoke$arity$2$' of undefined

sundbp21:11:00

it is indeed fixed, but didn’t give me much insight

thheller21:11:19

can you try with node --inspect the-thing.js so the source maps actually apply?

thheller21:11:05

or --inspect-brk

thheller21:11:20

that is an extremely weird line of JS

thheller21:11:13

it doesn’t even contain $cljs$core$IFn$_invoke$arity$2$

sundbp21:11:33

so i’ve never used node inspect/inspect-brk. I ran it - what do I do next?

thheller21:11:39

throw $done$jscomp$9_t__38328__auto__$jscomp$inline_1326$$ = $e38700$jscomp$inline_1327$$, that the heck is that? 😛

sundbp21:11:40

» node --inspect-brk bin/runner.js                                                                              ~15.0s 21:23:30
Debugger listening on 
For help see 

thheller21:11:58

oh you have chrome I assume?

sundbp21:11:06

ah. see docs link

thheller21:11:21

should show it

sundbp21:11:23

so it’s paused debugger at start of my runner

thheller21:11:35

yeah press the play button to run it

thheller21:11:59

click the pause on exceptions thing (pause icon)

thheller21:11:08

just in case it doesn’t stop automatically

sundbp21:11:31

ok. i don’t see any source-maps

sundbp21:11:28

but does indeed seem to be that utf-8 call

thheller21:11:20

yeah its not something the externs inference can detect properly

thheller21:11:33

(and not actually valid code if you want to be picky)

sundbp21:11:45

i don’t get the code to be honest

sundbp21:11:53

what’s the proper way to write that call?

sundbp21:11:12

(.readFileSync fs source "utf-8") ?

thheller21:11:35

(.. fs (writeFileSync source "utf-8))

thheller21:11:51

or better yet

thheller21:11:10

(fs/writeFileSync ...) coupled with (:require ["fs" :as fs]) in the ns

sundbp21:11:33

yeah, but in this case i think they wrote it for lumo, and that’s probably not gonna fly

thheller21:11:35

so the nodejs/require calls go away 😛

thheller21:11:46

lumo supports that

sundbp21:11:51

ah, it does. cool

thheller21:11:11

Antonio was the one that implemented the feature for CLJS core

thheller21:11:08

source maps indeed don’t work, looking into that

sundbp21:11:26

thanks for all the help

thheller21:11:40

np, happy to help.

sundbp21:11:49

i’m cleaning up aero and that’ll probaly be it + I learnt a bit about the process while doing it.

thheller21:11:25

dunno why they include that

sundbp21:11:55

btw, in this case i have a bin/runner.js, like your shadow-clj package. would that in any way throw source-maps off?

thheller21:11:33

it should not but it might. source maps are a bit funky in node sometimes

thheller21:11:00

it does load them correctly but it doesn’t use them.

sundbp21:11:25

i’ve used node for 2days so i’m totally new to the environment

thheller21:11:34

btw you can also add <project>/externs/pf.txt and just put the problematic things into it. so

hostname
writeFileSync

thheller21:11:36

don’t need to rewrite the entire code. manual externs still apply.

thheller21:11:57

check should also work again

koz21:11:34

@thheller really enjoying shadow-cljs so far, great work! Scrolling up in the channel, it seems like deps.cljs has to have the same information that already resides in the package.json file. Is there an easier way to keep the two in sync?

thheller21:11:09

check output

------ WARNING #3 --------------------------------------------------------------
 File: /Users/zilence/code/shadow-cljs/src/dev/demo/lib.cljs:13
--------------------------------------------------------------------------------
  10 |
  11 |
  12 | (def fs (js/require "fs"))
  13 | (fs.writeFileSync "x" "foo" "utf-8")
--------------------------------------------------------------------------------
 Property writeFileSync never defined on demo.lib.fs
--------------------------------------------------------------------------------
  14 |
--------------------------------------------------------------------------------

thheller22:11:05

@koz :npm-deps is only for libraries declaring dependencies on JS packages

thheller22:11:24

the project always uses package.json (since that drives npm which isn’t aware of :npm-deps)

thheller22:11:22

its kinda hard for them to sync since its undefined how conflicts should be handled

koz22:11:34

It would be cool if package.json served as the canonical, and shadow-cljs could generate deps.cljs from it. It seems like it could be potentially dangerous for packages to get out of sync if writing a lib (also another thing to remember).

thheller22:11:52

agreed. I have not yet done any work related to publishing libs with shadow-cljs, deps.cljs would be part of it.

sundbp22:11:34

@thheller ah, that’s good to know. I made PRs for the 2 libs I used that didn’t play ball, but good to know one can use official releases with externs while they await merge+release.

thheller22:11:40

it has come up before but I’m really unsure how to approach this issue

koz22:11:40

cool, it’s amazing how well this all works though. thanks for the response!

sundbp22:11:19

so far i’ve used: package.json has all node dependencies, nothing in deps.cljs/shadow-cljs.edn. shadow-cljs.edn has all cljs/clj dependencies. has been working ok sofar.

thheller22:11:36

yeah if I want publishing I need to mess with :profiles and such. I really don’t want to do that.

thheller22:11:26

but it needs a proper way to exclude some dev-only code from a lib .jar. same as lein/`boot`

thheller22:11:43

+ package.json handling which those don’t do

koz22:11:03

@sundbp we’re working with publishing this as a library that will be brought in from other cljs projects, so we need dependencies declared in the deps.cljs file

thheller22:11:10

probably not doing profiles, only :dev-dependencies or so

sundbp22:11:46

@koz ya, then I guess there’s no great way to keep it fully clean right now.

thheller22:11:47

but yeah publishing libs needs work

thheller22:11:59

@koz be careful when publishing libraries with :npm-deps though. pretty good odds they won’t work with anything but shadow-cljs

koz22:11:33

point taken. this is internal, so we have complete control over that thankfully

thheller22:11:39

:npm-deps pretty often does not work in CLJS core

sundbp22:11:07

@thheller it’d be awesome if source-maps for nodejs was to work - give me a shout if you think you know what’s wrong and there’s anything I can do to help. thanks!

thheller22:11:48

looking into it currently. the source map comment is not emitted for release currently but they don’t work in dev either which has the comments.

sundbp22:11:54

i guess it makes sense to not emit in release, but with the --debug flag for release it would make sense