Clojurians Log v2

Hi, I am running into TypeError: $jscomp.inherits is not a function when I am using a third party dependency (helix), one particular macro from it does it. I already tried to update and restart everything, I also added :output-feature-set :es8 to compiler options and I really wish I could do something that's not just guesswork but actual diagnostic and work. Any ideas?

which shadow-cljs version? this should be fixed for several versions now

I never know how to easily read version information. I am used to just add --version after cli commands and they print their version

it is printed clearly on each startup

shadow-cljs - server version: &lt;version&gt; running at <http://localhost:9630>

shadow-cljs info also works but only in limited ways if you use deps.edn or project.clj

i just do a shadow-cljs restart every time i need to start it, so it clear the usually stuck lock file from previous start

it doesn't print anything other than shadow-cljs - config: path/shadow-cljs.edn shadow-cljs - server starting .......................... ready!

ah you are running in the background

then its in the .shadow-cljs/server.stderr.log or .shadow-cljs/server.stdout.log

you told me to do it this way because i was having trouble managing 3 different terminal outputs. It's much better I admit

shadow-cljs - server version: 2.11.7

I am not sure this is shadow-cljs issue.

well there were several $jscomp related issues that I fixed recently but they should definitely be fixed in 2.11.7

would help to have a reproducible example

what is the actual build config you used?

https://gist.github.com/ashnur/a46a10fcc1fb153d46339376f4e055fc

not the tests, the app

looks fine except the :output-feature-set :es8 is only in the :release config. I'm assuming the problem you mentioned appears in watch/compile?

btw this is old and not needed anymore shadow.remote.runtime.cljs.browser in :preloads. you can just remove it.

ok, thanks

I will update. And the problem appears in the browser after I compiled and loaded it.

Didn't really wanted to do this, but I need class components because of react. I would avoid using them if I knew how, but ..

I see what you mean by the config only in the release. That would explain it, I will try in a minute, thanks

also in the :release the :modules and :output-dir are exactly the same as outside so you can remove it

😌

thanks again

I’m assuming it’s known that running shadow-cljs with the latest clojure cli tools appears to print a warning about invoking the clojure cli tools in a (recently) deprecated way: > WARNING: When invoking clojure.main, use -M

hmm? news to me 🙂

$ clojure -Sdescribe
{:version "1.10.1.716"
 :config-files ["/usr/local/Cellar/clojure/1.10.1.716/deps.edn" "/Users/rick/.clojure/deps.edn" ]
 :config-user "/Users/rick/.clojure/deps.edn"
 :config-project "deps.edn"
 :install-dir "/usr/local/Cellar/clojure/1.10.1.716"
 :config-dir "/Users/rick/.clojure"
 :cache-dir "/Users/rick/.clojure/.cpcache"
 :force false
 :repro false
 :main-aliases ""
 :repl-aliases ""}

ok I think the change is basically you now need to invoke clojure.main with clojure -M -m clojure.main

see here: https://insideclojure.org/2020/09/04/clj-exec/

well does that work with older versions? if not then I'm not changing that for a while

probably not

the command it runs is clojure -m shadow.cljs.devtools.cli --npm ...

sorry yeah you’ll need clojure -M -m shadow.cljs.devtools.cli ...

I haven't followed tools deps recently so dunno what changed

A lot

The main thing is the new :exec-fn and :exec-args stuff; which is pretty awesome actually… It could be interesting thinking about what it might mean for shadow-cljs… Though I imagine it’s a lot easier to just carry on with shadow-cljs.edn as it is 🙂

either way though it may open up some new options for you

yeah I'm not going to enforce using deps.edn on anyone. I don't use it on a single project of mine either.

its nice to see its moving forward but its still nowhere near lein for me

or shadow-cljs for CLJS of course 😉

I certainly know what you mean… it’ll be interesting to see what happens with tools.build

but the :exec-fn stuff at least now provides a way to integrate tooling to build a library and deploy it

it’s not yet as easy as it should be… but it would be pretty straightforward to make it as easy as lein to do this bit.

sure. if that some day is less than a 5 lines project.clj + lein deploy clojars I might support it 😉

but good thing is I don't have to do anything. everyone can already use it if they want

https://code.thheller.com/blog/shadow-cljs/2017/11/18/the-many-ways-to-use-shadow-cljs.html

still relevant and also still accurate describing why it won't use :exec-fn anytime soon

not less than yet… but it could at least now be made more or less equivalent. I currently have it down to about 30 lines of deps.edn with maybe 4 lines of bash: https://github.com/RickMoynihan/pom-update/blob/37d7bdb0eceb69af0f4796f4b9e7334db3f364a2/deps.edn#L13-L39

yikes 😛

IKR… if these libs were integrated together (I’ve done it already in a proprietary project which has slightly more bespoke needs - it could be done as easily as with lein)

give or take a few LOCs

yeah its interesting to see work in this area but so far everything looks kinda clunky

It’s definitely clunky — but :exec-fn makes things much better and feels like it could well be a decent foundation for new tooling

Yeah I definitely agree with your stance in that article… but I think :exec-fn is still relevant for shadow-cljs. i.e. if the shadow-cljs api defines entry point tooling functions to just be a single map of data, then they can work with :exec-fn, so users have more options for integration.

So shadow won’t need to mandate tools.deps and :exec-fn; but it could still be an option for users. Providing perhaps a few reasonable constraints are maintained

Anyway, as always thank you for your time 🙇 Shall I create a GH issue about the warning for you, just so there’s a record of it?

yes please

https://github.com/thheller/shadow-cljs/issues/802

Regarding character encoding in the repl. I'm connections via repl to a react-native app running on device:

lein repl :connect 9876                                        
Connecting to nREPL at 127.0.0.1:9876
REPL-y 0.4.4, nREPL 0.7.0
Clojure 1.10.1
OpenJDK 64-Bit Server VM 1.8.0_265-bre_2020_10_20_12_24-b00
...
shadow.user=> (println "Smørrebrød")
Smørrebrød
nil
shadow.user=> (shadow/repl :app)
To quit, type: :cljs/quit
[:selected :app]
cljs.user=> (println "Smørrebrød")
Sm??rrebr??d
nil

For me it looks like the JavaScript environment on device uses a different character encoding.

that might be. I don't have a clue about react-native sorry

It's a little strange that the JVM "runs" on US-ASCII

lein repl :connect 9876
shadow.user=> (System/getProperty "file.encoding")
"US-ASCII"

ah

someone had this issue before. I cannot remember the details

So I suspect I should have the same char encoding in the Java world than in the JavaScript world running on device.

how is shadow-cljs launched?

shadow-cljs watch app

I have a JVM_OPTS environment variable with -Dfile.encoding=UTF8

and you have :lein true or something in shadow-cljs.edn?

no

I'm using tools.deps

then why did you mention is in the arguments of the java process of lein`? `?

i only start the repl with lein

right but the shadow-cljs server process needs to have the same encoding

otherwise that won't work

so you can set :jvm-opts ["-Dfile.encoding=UTF8"] in shadow-cljs.edn

Same issue/problem with the repl when running in IntelliJ with Cursive

I'll try....

Of course the US-ASCII is not from the lein-JVM but from the shadow-JVM... stupid me!

Okay, thanks, cool. Setting :jvm-opts ["-Dfile.encoding=UTF8"] in shadow-cljs.edn fixed the problem.

Why is it US-ASCII bei default? When I launch clj I get:

% clj 
Clojure 1.10.1
user=> (System/getProperty "file.encoding")
"UTF-8"

Although UTF8 works, I guess it should be UTF-8.

how can I depend on a local built jar (path to jar) ? I'm working to patch https://github.com/titonbarua/shadow-cljs-gjs-target/pull/2 to allow for Gnome Extension to be built. I need to make [[titonbarua/shadow-cljs-gjs-target "0.1.0"] -> [[ shadow-cljs-gjs-target "0.2.0-gnome-extension-patch"]] I can build the patch locally

@eugen.stan you can run lein install to install it locally

or in the examples :source-paths you can just direclty include the code via "../../src" and no :dependencies

thanks, I will try both

including source-paths in shadow-clj.edn of example/gnome-extension.. project does not work (it will not pull the dependencies of that one)

I can use lein install

https://github.com/titonbarua/shadow-cljs-gjs-target/blob/master/project.clj#L6 but it doesn't have dependencies?

(after nap) Thanks, I was using the wrong path. I can compile and work on the integration now. Made some progress but not quite there yet. It's doable though and we will be able to build GTK apps for gnome shell (Gnome extensions) in ClojureScript