This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-06
Channels
- # adventofcode (1)
- # aleph (9)
- # announcements (22)
- # beginners (59)
- # boot (8)
- # calva (1)
- # cljdoc (7)
- # cljs-dev (10)
- # cljsrn (9)
- # clojars (10)
- # clojure (23)
- # clojure-dev (6)
- # clojure-europe (3)
- # clojure-italy (26)
- # clojure-nl (3)
- # clojure-seattle (1)
- # clojure-spec (46)
- # clojure-uk (85)
- # clojurescript (97)
- # core-async (13)
- # cursive (3)
- # data-science (10)
- # datomic (156)
- # duct (34)
- # emacs (37)
- # figwheel (3)
- # figwheel-main (9)
- # fulcro (59)
- # hyperfiddle (4)
- # immutant (1)
- # jackdaw (3)
- # jobs (1)
- # off-topic (112)
- # parinfer (1)
- # qlkit (2)
- # re-frame (1)
- # reagent (35)
- # ring-swagger (2)
- # shadow-cljs (104)
- # spacemacs (9)
- # speculative (12)
- # tools-deps (30)
- # yada (10)
for the calva plugin in vscode, is there a way to pretty print the results on the terminal window?
@thheller Hey Thomas, I think we might have run into a weird bug in shadow cljs
shadow.cljs.util/is-jar?
does a simple endsWith
check to see if the string is a jar
however in our internal setup, Buck generates directories that end with .jar
¯\(ツ)/¯
that’s causing a weird error in our build
FileNotFoundException: /Users/anmonteiro/Documents/github/ladder/buck-out/gen/src/ladder/__common_lib__/common.jar (Is a directory)
java.util.zip.ZipFile.open (ZipFile.java:-2)
java.util.zip.ZipFile.<init> (ZipFile.java:219)
java.util.zip.ZipFile.<init> (ZipFile.java:149)
java.util.jar.JarFile.<init> (JarFile.java:166)
java.util.jar.JarFile.<init> (JarFile.java:130)
shadow.build.classpath/find-jar-resources* (classpath.clj:455)
shadow.build.classpath/find-jar-resources* (classpath.clj:452)
shadow.build.classpath/find-jar-resources (classpath.clj:579)
shadow.build.classpath/find-jar-resources (classpath.clj:553)
shadow.build.classpath/find-resources (classpath.clj:627)
shadow.build.classpath/find-resources (classpath.clj:625)
shadow.build.classpath/index-path* (classpath.clj:854)
shadow.build.classpath/index-path* (classpath.clj:851)
clojure.lang.PersistentVector.reduce (PersistentVector.java:343)
clojure.core/reduce (core.clj:6827)
clojure.core/reduce (core.clj:6810)
shadow.build.classpath/index-classpath/fn--1940/fn--1941 (classpath.clj:973)
clojure.lang.Atom.swap (Atom.java:37)
clojure.core/swap! (core.clj:2352)
clojure.core/swap! (core.clj:2345)
shadow.build.classpath/index-classpath/fn--1940 (classpath.clj:973)
shadow.build.classpath/index-classpath (classpath.clj:972)
shadow.build.classpath/index-classpath (classpath.clj:967)
shadow.build.classpath/index-classpath (classpath.clj:969)
shadow.build.classpath/index-classpath (classpath.clj:967)
shadow.cljs.devtools.server.common/fn--6874 (common.clj:89)
shadow.cljs.devtools.server.common/fn--6874 (common.clj:87)
this is the relevant stack trace
expanded with a little more info
@thheller this is using 2.7.25 btw
I tried to override is-jar?
with:
(defn is-jar? [^String name]
(let [f (java.io.File. name)]
(and
(not (.isDirectory f))
(.endsWith (str/lower-case name) ".jar"))))
yeah the check just naively assumes that things ending in .jar
are actually jars not directories
but that doesn’t work either because name
is just "common.jar"
in this case
so I think it’d need to be the full path
not sure if that makes things harder or not 😛
this also only started happening when I bumped shadow from 2.7.12 to 2.7.25
not sure why that would be, but it could be my fault instead of shadow’s
given that our dep management is pretty gnarly
kind of new to this bit — is there any way to specify a path in shadow-cljs.edn
to an npm dependency’s CSS such that it works in dev and in a release artifact?
@anmonteiro nothing in that regard really changed since 2.7.12 so maybe something in your build setup changed?
yeah that might be the case, I need to investigate further
does buck
only do this for release builds? some dev features treat files in jars a bit differently and won't warn as aggressively for example
I’m not sure
hrm so the difference between 2.7.25 and 2.7.12 in our setup is that the directory ending in .jar
is never in the dep graph in 2.7.12
I’m still not sure why that is though
that is weird. the error happened when the classpath was indexed which happens before any CLJS compilation is even involved
@anmonteiro 2.7.26
should fix it
trying now
I actually built a jar from master now that I saw your commit
yeah I think it did work
thanks!
was about to push a release anyways since I wanted to test a new feature I was working on 🙂
@thheller soo there’s another “issue” in 2.7.26 related to this
you’re now throwing an error classpath entry that is not a directory or jar file
but I’m not sure if you need to be this strict
we have a shared library .so
in the classpath that is neither a jar nor a directory 😛
I think it is, for bindings to native code
through the JNI
I can work around this one, just wanted to provide feedback
pretty sure that still needs the full filename and can't be the classpath entry itself
this seems to be allowed
we’ve had this for a while and java hasn’t complained
wrt why we started hitting this, did you perhaps change anything between 2.7.12 and 2.7.25 wrt. laziness / eagerness?
@anmonteiro pushed 2.7.27
that just silently ignores anything but directories or regular files that end in .jar
thank you sir
the last related change to the classpath was in 2.7.6
which reworked how symlinks are handled
@thheller does clojurescript need to be a hard dependency for shadow btw?
yes because sometimes things are added in master that break shadow-cljs. like when 449 added new bindings in cljs.analyzer that would cause nullpointerexceptions since shadow-cljs didn't properly bind them
most of the time master just works, just sometimes things break so its safer to always set a depdendency
yeah being a hard dep for API compat makes sense
I just asked because we use the "slim"
classifier and were getting the normal AOTed compiler on every shadow dep resolution
in fact the whole reason why I found this bug in the first place was because we had 1.10.516 on shadow 2.7.12 and it was telling me clojure.edn
didn’t exist
so I went to upgrade shadow
hmm if you had 1.10.516 you should have had clojure.edn? your dep should always be picked over the shadow-cljs dep?
so it compiled fine without trouble
but when I changed the config.edn file, the browser said the bundle was out of date
and the terminal gave a warning that clojure.edn
didn’t exist so it would skip compilation
I don’t know what those words mean 😄
the npm package is rather strict because people in the past had old clojurescript in their :dependencies
that might be the case
(I didn’t set it up)
https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/npm/cli.cljs#L214
it’s a pretty frankensetup
this would be the (very outdated) extracted version of it https://github.com/ladderlife/loonie
shouldn't need anything beyond just keeping the .shadow-cljs/builds
directory around between compiles
Buck’s notion of caching is a little different, and more holistic
@thheller last issue we’ve found with Shadow
we’re running a fork of shadow actually, because the source maps were embedding our entire source code in production 🙂
https://github.com/ladderlife/shadow-cljs/commit/8e18cb6219c749219d3d45e778af3b6e7e085aa1
^ this is the current diff we applied to shadow
but we aren’t sure that’s the correct patch
we’d love to not run a fork too 🙂
well in the stacktraces we report to sentry we just need to get the filenames and line numbers
makes sense. I'll take a look at it later. https://github.com/thheller/shadow-cljs/issues/434
thanks!
I could use some help in testing this new thing I added today https://clojureverse.org/t/smaller-builds-with-lots-of-js-dependencies/3742