should builds not fail when a warning/error comes up like this?

npm package "slate-react" expected version "react-portal@^3.1.0" but "4.1.5" is installed.
npm package "slate" expected version "direction@^0.1.5" but "1.0.2" is installed.

or, is it possible to fail builds when this happens?

not currently possible to fail builds due to that no.

it is also pretty much unfixable

since if you install the new version the other packages that were expecting the older versions will complain

ah

cause we hit a compilation bug with this and so i’m a bit weary of it going unnoticed

is it possible this can happen “randomly”, when deps have not been touched?

well if they haven't been touched no

but npm install isn't exactly deterministic

so just running npm install again may produce different results

I will be adding additional functions for the UI for this so that you can run something like deps-check so see potential version conflicts and fail if there are

don't actually need to compile for that

has anyone ever seen a problem for Symbol is undefined in IE11?

http://kangax.github.io/compat-table/es6/#test-Symbol

ah i see

not supported in ie11

not supported

would need a polyfill

yeah

do you know of any good polyfills/practices for this?

depends on what you are doing and where you are doing it? are you using Symbol or is it a npm lib?

(react uses symbol but self-polyfills it if not available typically)

npm lib

all the online answers point to babel which i cannot/don’t want to use

hmm closure should detect the use of Symbol and inject accordingly

do you have a :language-out configured in your :js-options?

nope

{:app {:target     :browser
        :output-dir "resources/cognician/manage/js/"
        :asset-path "/cognician/manage/js/"
        :devtools   {:loader-mode     :eval
                     :ignore-warnings true}
        :modules    {:app {:entries [cognician.manage.app]}}
        ;; build env specific settings
        :dev        {:compiler-options {:ignore-warnings true}
                     :closure-defines  {cognician.manage.DEBUG true
                                        goog.DEBUG             true}}
        ;; production
        :release    {:compiler-options {:infer-externs :auto
                                        :source-maps   true}}}}

which npm lib?

slate

getting a link now

https://github.com/ianstormtaylor/slate

and with it, slate-react (react counterpart lib)

I'm a bit busy right now. I'll check later why the symbol polyfill isn't added.

are you trying in dev or release or both?

i’ve yet to try dev, i’ll try that now

no worries man, thank you for the bit of help

you can maybe cheat and just use js/Symbol in your CLJS

and then set :compiler-options {:rewrite-polyfills true}

but the entire polyfills handling is a bit weird right now

since JS typically injects their own polyfills all over the place

i’ll try that out, thank you

I'm not quite sure what I am doing wrong. But when I use deps.edn shadow-cljs can't find the namespace I use for clj-run.

is it on the classpath?

It runs fine when I am declaring dependencies the normal way in the shadow-cljs.edn file.

that doesn't answer my question 😛

Well I assume it is on the classpath. I'm still kind of in the dark on a lot of the JVM stuff. lol

what are your :source-paths? and does the deps.edn have matching :paths?

:source-paths are here. https://github.com/groundedSAGE/shadow-jam/blob/master/shadow-cljs.edn#L3

you need to add those via :paths to deps.edn too

That fixed it. Cheers!

@biscuitpants i just did a polyfill straight at the top of my index.html. ie11 doesn’t support Array.find natively, which was about the only older version incompat I found with cljs.

but the rewrite polyfills option didn’t seem to work for that particular case, hence the direct inclusion

ah okay, that’s a good idea. i’ll try that

i remember boot-clj has a :checkouts option which was useful for pointing to a local jar instead of a published mvn artifact. to do the equivalent in shadow do I just add the dir to the :source-paths config? i feel like I read somewhere that shadow-cljs cannot modify the classpath above/outside its root, but not sure if that’s right

@lwhorton completely fine to add :source-paths to wherever. the rule for non-project files is only for node_modules

:thinking_face: I just upgraded from 2.4.24 to 2.6.8 and I'm getting a bunch of inference warnings. I think I ran into this before...

do you maybe have a pinned clojurescript version?

ah yeap

remembering now 😅 I have a pinned clojurescript + closure-compiler that I needed to remove to upgrade

Is there anything like Prettier for cljs/reagent?