also added https://github.com/thheller/shadow-cljs/issues/609 so I don't forget

how long do you think it might take to fix the naming issue?

might take care of it tommorrow

too tired to do it now

Cool, no rush, thx

hey, just wanted to say yet again, that shadow-cljs is such an amazing tool 🙂 very happy to be using it daily.

Hi I am trying to consume vis-network as a npm-package using the ns require form

(my.ns
  (:require [reagent.core :as r]
            ["vis-network" :as vis]
            [clojure.string :as str]))

Resource: node_modules/vis-network/dist/vis-network.min.js:2
 constant module$node_modules$vis_network$dist$vis_network_min assigned a value more than once.
Original definition at externs.shadow.js:4

@iku000888 not sure what you mean. the warning you get can be ignored. what about the if you posted? looks like its checking the arity of a function? maybe one you passed in? (fn [arg1 arg2] ..)?

@pavel.klavik I added :release-version in 2.8.77 see https://shadow-cljs.github.io/docs/UsersGuide.html#release-version

Thx, looking at it. I am currently building uberjar like this in project.clj:

["clean"
 ["run" "-m" "shadow.cljs.devtools.cli" "release" "client"]
 "compile"
 ["less" "once"]]

I'd probably create something like the release fn described here https://shadow-cljs.github.io/docs/UsersGuide.html#clj-run

and then just run -m my.build/release from lein

(shadow/release :my-build {:config-merge [{:release-version "v1"}])

note the extra vector that is currently required (since you are allowed to use --config-merge multiple times too)

I'm trying to upgrade the version of shadow-cljs that my :npm-module uses, but I'm finding that (from version 2.8.69) :closure-defines in shadow-cljs.edn isn't overriding the default values. Did something change in how that's configured? The documentation doesn't seem to differ from what I have. Though for my current purpose I should be able to use goog.DEBUG, since that appears to still get set.

@thheller thx for the quick, got it working with git commit ids; for anyone running on Heroku, this is very useful: https://devcenter.heroku.com/articles/dyno-metadata

Hmm, apparently the defines weren't the only thing preventing my devtools from working. I'm currently using (js/require "ardoq-sheet-load/build/npm/shadow.cljs.devtools.client.browser") to load the devtools while my module is embedded in our main app. This worked previously, but appears to no longer be enough/correct?

@mel.collins if you are using project.clj or deps.edn then it is likely you just have a version conflict on the closure compiler/library releases

should be

[com.google.javascript/closure-compiler-unshaded "v20191027"]

   [org.clojure/google-closure-library "0.0-20191016-6ae1f72f"]
   [org.clojure/google-closure-library-third-party "0.0-20191016-6ae1f72f"]

Hmm, I don't have any of those in my deps.edn right now

@thheller tried adding those versions explicitly, and it didn't change either of the issues I'm experiencing. 😞 For the defines issue, I can see in the browser console that $CLJS.CLOSURE_DEFINES contains myproject.core.EMBEDDED_DEV: true, but returning the value from a function within myproject.core returns false. 😕 To the devtools not working, I can see $CLJS.shadow.cljs.devtools.client.browser contains a bunch of functions and whatnot, so I guess it's being imported in some capacity, but none of the functionality is evident. Could the websocket be failing to connect silently? Not sure how to debug that. 😕

Hm. 2.8.68 is the most recent version where either of them work for me. Suggestions for fixing/debugging welcome, but otherwise I guess I'm going to have to stay on that release until I have more time/priority to investigate upgrading further. 😞

@mel.collins which version did you try? 2.8.77 should definitely work everything before .76 may have had a problem

.69 was the version that bumped the closure compiler/library so I'm fairly certain that is your issue

Are there any settings I can change to prevent “Too many open files” errors?

besides upgrading? haven't had any reports about that for a while now? which version are you on?

@thheller that did it! 2.8.51 -> 2.8.77 fixed it

@thheller I was just testing :loader-mode :script and it works for WebWorker but source maps then don't work for the main code.

hmm? I've been using workers all day and that worked fine?

make sure you have :asset-path configured correctly though

:output-dir       "resources/public/js/compiled"
:asset-path       "/js/compiled"

looks good. dunno why it wouldn't work then?

It does display the error in a readable form, but when I click at a cljs file, Chrome opens the corresponding js files (and it states in the top that source maps are available, but it does not use them for whatever reason)

and when I set :loader-mode to default, everything works fine

dunno. that uses the same source maps.