Fork me on GitHub
#shadow-cljs
<
2020-11-20
>
Aron09:11:44

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?

thheller09:11:47

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

Aron09:11:54

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

thheller09:11:11

it is printed clearly on each startup

thheller09:11:25

shadow-cljs - server version: <version> running at

thheller09:11:46

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

Aron09:11:19

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

Aron09:11:56

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

thheller09:11:11

ah you are running in the background

thheller09:11:51

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

Aron09:11:52

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

Aron09:11:43

shadow-cljs - server version: 2.11.7

Aron09:11:55

I am not sure this is shadow-cljs issue.

thheller09:11:36

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

thheller09:11:46

would help to have a reproducible example

thheller09:11:53

what is the actual build config you used?

Aron09:11:26

not the tests, the app

thheller09:11:21

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?

thheller09:11:00

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

Aron09:11:18

ok, thanks

Aron09:11:47

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

Aron09:11:49

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 ..

Aron09:11:11

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

thheller09:11:01

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

Aron09:11:27

😌

Aron09:11:33

thanks again

rickmoynihan10:11:13

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

thheller10:11:57

hmm? news to me 🙂

rickmoynihan10:11:46

$ 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 ""}

rickmoynihan10:11:00

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

thheller10:11:25

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

thheller10:11:39

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

rickmoynihan10:11:05

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

thheller10:11:06

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

rickmoynihan10:11:14

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 🙂

rickmoynihan10:11:35

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

thheller10:11:58

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

thheller10:11:30

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

thheller10:11:00

or shadow-cljs for CLJS of course 😉

😆 3
rickmoynihan10:11:09

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

rickmoynihan10:11:01

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

rickmoynihan10:11:49

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.

thheller10:11:52

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

rickmoynihan10:11:09

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

thheller10:11:55

yikes 😛

rickmoynihan10:11:22

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)

rickmoynihan10:11:51

give or take a few LOCs

thheller10:11:22

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

rickmoynihan10:11:24

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

thheller10:11:19

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

thheller10:11:08

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

rickmoynihan10:11:05

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.

rickmoynihan10:11:00

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

rickmoynihan10:11:30

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?

defa12:11:16

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
In the "Java REPL" encoding is okay, in the "JS REPL" it is broken... any ideas on how to fix that?

defa12:11:04

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

thheller12:11:52

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

defa12:11:13

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

lein repl :connect 9876
shadow.user=> (System/getProperty "file.encoding")
"US-ASCII"
despite the fact that -Dfile.encoding=UTF-8 is in the arguments of the java process of lein?

thheller12:11:32

someone had this issue before. I cannot remember the details

defa12:11:38

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

thheller12:11:43

how is shadow-cljs launched?

defa12:11:00

shadow-cljs watch app

thheller12:11:03

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

thheller12:11:25

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

defa12:11:07

I'm using tools.deps

thheller12:11:08

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

defa12:11:16

i only start the repl with lein

thheller12:11:29

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

thheller12:11:32

otherwise that won't work

thheller12:11:49

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

defa12:11:02

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

defa12:11:09

I'll try....

defa12:11:45

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

defa12:11:42

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

defa12:11:14

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"

defa12:11:06

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

Eugen13:11:54

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

thheller13:11:15

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

thheller13:11:31

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

Eugen13:11:40

thanks, I will try both

Eugen13:11:29

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

Eugen13:11:40

I can use lein install

Eugen23:11:31

(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

Eugen00:11:01

my main issue right now is to disable minification for some function: init, enable and disable. gnome shell calls those function to do the work. But the current setup minifies those names.