shadow-cljs 2023-01-22 | Slack Archive

hifumi12312:01:57

Would it be possible to integrate something like webpack's style-loader into shadow-cljs or am I better served with using something like Garden? I ask because I'm dealing with a pesky React component that unfortunately wants to be passed an embedded stylesheet. For now my best guess would be to define a macro that simply slurps an external CSS file and I mimic the import "stylesheet.css" syntax by naming my macro something like import-css

thheller12:01:10

there is no built-in support for this. and it is not possible to use style-loader directly, other than actually using webpack

hifumi12312:01:19

Makes sense. For now I'm just going to stick with my macro idea. Hopefully React components dont mind being fed a gigantic CSS string 😄

thheller12:01:50

style-loader creates a JS object with classnames IIRC, so a string won't do

hifumi12313:01:12

Oh yeah, React isn't happy with my provided styles being strings. Looks like I have to figure out something different... In any case, thanks for the help

Akiz13:01:12

Hi, i am trying to run shadow-cljs via deps.edn 1. it means i dont have it install via npm, right? 2. i am getting this error when cider-jack-in-cljs

error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: ------------------------------------------------------------------------------

   WARNING: shadow-cljs not installed in project.
   See 

------------------------------------------------------------------------------
shadow-cljs - config: /Users/akiz/Code/Clojure/hh/shadow-cljs.edn
shadow-cljs - starting via "clojure"
--- SHADOW-CLJS FAILED TO LOAD! ----------------------

Akiz13:01:07

I made sure that i have got the exact version of dependencies from here: https://clojars.org/thheller/shadow-cljs This is the cause:

Caused by: java.lang.NoClassDefFoundError: com/google/common/collect/Streams
	at com.google.javascript.jscomp.deps.ModuleLoader.createRootPaths(ModuleLoader.java:259)
	at com.google.javascript.jscomp.deps.ModuleLoader.<init>(ModuleLoader.java:154)
	at com.google.javascript.jscomp.deps.ModuleLoader$Builder.build(ModuleLoader.java:146)
	at com.google.javascript.jscomp.deps.ModuleLoader.<clinit>(ModuleLoader.java:414)
	at com.google.javascript.jscomp.DiagnosticGroups.<clinit>(DiagnosticGroups.java:178)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:167)
	at clojure.lang.Compiler$StaticMethodExpr.eval(Compiler.java:1743)
	... 211 more
Caused by: java.lang.ClassNotFoundException: com.google.common.collect.Streams
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
	... 222 more

Akiz14:01:18

I solved it by adding com.google.guava/guava {:mvn/version "31.1-jre"} to deps.edn

👍 2

thheller20:01:50

it is still strongly recommended to install the npm package

hifumi12322:01:40

Seconded. I've used shadow-cljs with leiningen in the past, but it was mostly to integrate existing projects tied together with lein-parent or lein-monolith. For standalone CLJS projects, using the NPM package saves you from tons of pain. There's absolutely no need for deps.edn or leiningen unless it's to integrate with an existing project of yours imo

thheller06:01:36

that is not the reason to install the npm package and is not related to deps.edn or lein at all

thheller06:01:58

the reason is just that the npm shadow-cljs package also brings in some other relavant npm packages you may need when using shadow-cljs builds

thheller06:01:11

eg. the ws package when using node targets

👍 2

thheller06:01:03

otherwise using shadow-cljs.edn to manage cljs dependencies, or deps.edn/project.clj doesn't really matter. other than sometimes having manual dependency conflicts

Akiz09:01:36

Thanks. I can’t remember why I chose deps.edn this time. Does it have any advantage over using npm (except that I manage dependencies in one file)?

thheller13:01:55

it is absolutely fine to use deps.edn. the only difference is that you need to take care of dependency conflicts yourself. with shadow-cljs.edn the shadow-cljs tool can prevent some conflicts, so that is the advantage

thheller13:01:18

but again this has absolutely nothing to do with the npm installed shadow-cljs package. that is a separate tool that I made the unfortunate choice to give it the same name

thheller13:01:03

consider the npm shadow-cljs package toa ctually be shadow-cljs-cli. it only handles the shadow-cljs command line tool and nothing else. not related to CLJS compilation in any way

thheller13:01:32

deps.edn has the advantage of supporting :local/root and :git/url dependencies, as well as being sort of the new standard

👍 2

2023-01-22

Channels