Fork me on GitHub
#shadow-cljs
<
2020-02-20
>
Jean06:02:19

Hello 🙂 Does anyone try to use @material-ui/icons ? I have a weird error when I import:

["@material-ui/icons/Menu" :default menu-icon]  => Module not provided: module$node_modules$$material_ui$icons$Menu
The module exists on path node_modules/@material-ui/icons/Menu.js

aisamu11:02:19

This looks OK. Is this the only icon that fails? I'd check your version of @material-ui/icons - you have to import it separately

Jean15:02:41

Yes @material-ui/icons is imported separately. Works with @material-ui/icons/esm/Menu

paul a17:02:23

regarding my issue from a few days ago where i was getting compilation errors without a stack trace, it seems to have been because i was trying to inline in my CLJS file a weird Java object via a clojure macro. 🤷

paul a17:02:26

that said, i'm inlining over 4 MB of data...

thheller17:02:32

eek don't do that 😛

😅 4
pre20:02:54

I've used shadow-cljs before successfully. However a new project template with a reagent and a lein based project.clj deps, is throwing the following error on shadow-cljs watch: How do I debug this?

$ shadow-cljs watch app
shadow-cljs - config: /home/.../shadow-cljs.edn  cli version: 2.8.83  node: v12.3.1
shadow-cljs - socket connect failed, server process dead?
shadow-cljs - running: lein run -m shadow.cljs.devtools.cli --npm watch appshadow-cljs - running: lein run -m shadow.cljs.devtools.cli --npm watch app
Exception in thread "main" Syntax error compiling . at (shadow/build/closure.clj:69:5).
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:7115)
	at clojure.lang.Compiler.analyze(Compiler.java:6789)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:7095)
	at clojure.lang.Compiler.analyze(Compiler.java:6789)
	at clojure.lang.Compiler.analyze(Compiler.java:6745)
	at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:7109)
    ...
    ...
Caused by: java.lang.NoSuchFieldException: getRegisteredGroups
	at java.base/java.lang.Class.getField(Class.java:1999)
	at clojure.lang.Compiler$StaticFieldExpr.<init>(Compiler.java:1284)
	at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:1006)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:7107)
	... 188 more

lilactown20:02:54

the versions in the solution might be out of date, but the general advice is still good: make sure that you’re specifying the same clojurescript, closure-compiler-unshaded and google-closure-library versions as shadow-cljs

thheller20:02:22

yes that is caused be a conflicting closure-compiler version

pre21:02:13

thanks @lilactown @thheller. How do you expect future users of shadow, using future versions of cljs and lein would not run into this issue?

thheller21:02:59

I always recommend people use shadow-cljs.edn for dependencies .. then you don't have to worry about such things

thheller21:02:10

if you use lein then you must deal with conflicts .. that is your choice

thheller21:02:54

but you really don't have to do much to sort it out in lein ... just figure out where you conflicts are coming from and fix them

pre21:02:58

the following seems to be a better, fool proof way, to avoid future conflicts.

[org.clojure/clojurescript "1.10.597"
    :exclusions [com.google.javascript/closure-compiler-unshaded
                 org.clojure/google-closure-library
                 org.clojure/google-closure-library-third-party]]

thheller21:02:01

lein deps :tree will likely tell you

thheller21:02:28

that isn't fool proof either. you might still get bad versions from other things

Prometheus21:02:35

Hey does anybody have any experience with deploying shadow-cljs apps to heroku? Do I need to deploy it as a node app or is there another way? I see heroku only allows for lein apps when it comes to clojure.

p-himik15:02:23

If that's still relevant to you, I have a Clojure[Script] app on Heroku. But it's not as dev-friendly as it could've been right now because it wants you to use Lein - I had to strip down their build pack to a bare minimum and to write my own bash code to build CLJS with shadow-cljs.

thheller21:02:06

what do you want to "deploy"?

Prometheus21:02:52

just a webapp that I made with shadow-cljs

Prometheus21:02:01

so in a browser I guess

thheller21:02:20

so its just client side JS, no server side?

Prometheus21:02:23

my experience with deploying webapps is minimal to say the least

Prometheus21:02:28

no serverside no

Prometheus21:02:40

just a simple MVP proof of concept frontent reagent/re-frame app

thheller21:02:12

I don't know anything about heroku but there likely is some option to deploy some static files?

thheller21:02:16

ie. just copy them there?

dpsutton21:02:33

netlify is amazing for static cljs sites

Prometheus21:02:57

yes but it seems to want me to deploy it as a php app and mess around with the filenames, creating an index.php and renaming my index.html

pre21:02:17

lein provides a lot more functionality (plugins, cider integration, templates) than shadow/deps.edn/lumo, and likely not going away. I've used it for 6+ years and has a lot more stability. It would be better to document dependency issues while integrating with other tools, than to wait till someone has to stackoverflow them.

Prometheus21:02:45

netlify, I’ll check it out @dpsutton

Prometheus21:02:10

Hmm this feels a little bit too easy if you ask me 😉

Prometheus21:02:37

@pri so you’re saying I should just use lein?

pre21:02:09

No. We should be aware of dependency conflicts while using multiple tools together. I only have this issue with lumo/shadow as they bundle their own versions.

lilactown21:02:02

I don’t think he was replying to you, @peder.august

🙃 4
thheller21:02:20

@pri it isn't easy to document those kind of issues. a) they likely change between versions b) they depend on whatever else you are using

thheller21:02:53

your fix might not work for others, other fixes might not work for you

thheller21:02:32

its annoying I know ... I don't like it either but the closure-compiler folks aren't very concerned about backwards compatibility

thheller21:02:36

so sometimes they break stuff

thheller21:02:58

but we still want to use semi recent versions because they also keep adding stuff thats relevant to the JS integration

👍 8