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
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 :simple_smile:
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