we're still seeing some inference warnings when using satisfies? - wondering if this is being tracked already? i can try to make a repro case if useful too

I don't recall any remaining open issues surrounding satisfies? and type inference, so a JIRA with minimal repro would be useful

@roman01la just not interested in changing the string concatenation because of Jsonp api changes, as @thheller alludes the issues are too subtle

you need to follow Closure conventions here - we're not going to make it more convenient

we encountered the same thing with the code splitting loader - goog.html.legacyconversions.safeUrlFromString works just fine

so :npm-deps {package "1.2.3"} is incompatible with :target :bundle ?

also if folks specify :install-deps the compiler throws an error.

[Figwheel:SEVERE] java.lang.IllegalArgumentException: contains? not supported on type: java.lang.Boolean

Oh, I thought I'd broken that. ^ I've reproduced that myself.

because :npm-deps is true

There just needs to be a guard in the meantime

:npm-deps means something slightly different now

it really just declares dependencies

:install-deps is still there and uses :npm-deps, but it's so slow

clj -m cljs.main --install-deps preferred

instead of putting in your build config which slows down build and REPL

the other thing that :npm-deps does is notify the compiler needs to index node_modules

There is a bug where merge overwrites :npm-deps with true, and calling :install-deps throws when using the :bundle target

it throws here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2380

that's a bit too succinct for 2 bug reports

is that one thing or two things?

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2508

its really one thing

:install-deps conflicts with :bundle

becase add-implicit-deps overwrites :npm-deps with true

and then install-deps expects a map

@bhauman fixed in master

thanks!

this was an issue that @gdanov debugged this morning

https://github.com/bhauman/figwheel-main/issues/247

just tweaked check-npm-deps to handle the boolean case for :npm-deps

in truth :bundle is just sugar

you could have encountered this with just compiler options

i.e. upstream node deps + :install-deps true

its fair to say that folks should not have deps specified in :npm-deps when wanting a bundle target?

@bhauman :bundle is specifically designed to work :npm-deps

to add values to it

?

it's designed to work with it period

you need to be able to declare deps and get upstream deps

this gets you ClojureScript libs that depend on node_modules instead of CLJSJS etc.

yeah from what I understood, :bundle means that as a lib author I should def start including :npm-deps in a deps.cljs in my lib

if there’s something broken with :npm-deps and :bundle then I’d assume it’s a bug

Krell depends on this feature, and I believe some demos/examples have been made

OK my main question is: Is it intended that :bundle will always set :npm-deps to true, even if its populated with deps declarations?

oh that's a bug if it overwrite

yes that’s what I was getting at 🙂

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2508

in this clause it gets overwritten

I’m super close to releasing the next version of figwheel that supports all of this better and I just wanted to clarify things

@bhauman yeah I didn't notice it because I stopped using :install-deps true

fixing

yeah definitely two different bugs, both fixed now @bhauman

those were tough ones for folks switching over

yeah pretty bad bugs, let me know when you want me to cut another release to depend on

yeah a new release pretty soon would be great

started one now

@bhauman 1.10.773

@dnolen I know I asked before, but if I wanted to programmatically install deps, is there another api I should use? Probably the same one as cljs.main?

yes same as cljs.main

@dnolen thanks!

np