This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-08
Channels
- # announcements (5)
- # aws (15)
- # babashka (7)
- # beginners (138)
- # bristol-clojurians (2)
- # chlorine-clover (11)
- # cider (9)
- # clara (4)
- # clj-kondo (17)
- # cljsrn (20)
- # clojars (1)
- # clojure (73)
- # clojure-europe (17)
- # clojure-italy (1)
- # clojure-nl (9)
- # clojure-spec (4)
- # clojure-uk (9)
- # clojurescript (43)
- # data-science (1)
- # datomic (87)
- # emacs (2)
- # figwheel-main (30)
- # fulcro (71)
- # helix (2)
- # hugsql (4)
- # jackdaw (5)
- # jobs (3)
- # jobs-discuss (31)
- # juxt (5)
- # kaocha (6)
- # lein-figwheel (16)
- # leiningen (1)
- # luminus (4)
- # malli (2)
- # meander (54)
- # music (8)
- # nrepl (12)
- # observability (28)
- # off-topic (85)
- # pathom (11)
- # re-frame (99)
- # reitit (9)
- # ring (1)
- # rum (6)
- # sci (11)
- # shadow-cljs (102)
- # sql (22)
- # tools-deps (10)
- # vim (65)
- # xtdb (14)
@mel.collins I removed the forced override in master
. will probably make a release later.
I’ve got my build into a state where whenever I restart it, I get a message: server pid exists but server appears to be dead, proceeding without server
, and then my build hangs when compiling. Is there an easy way to just reset everything and force a clean build?
@cfleming unlikely that fixes anything but you can delete .shadow-cljs/builds
. does it actually hang completely? does it max out cpu?
I've had weird reports of "hangs" when using incompatible core.async versions? did you maybe change versions?
No, I’m not using core.async (well, some of the machinery via promesa, but not directly)
Ok, I’ll do that. I’m using a project.clj but perhaps I should just switch to a pom.
pid doesn't matter. it is just telling you that the server probably did shut down cleanly
hehe. its fine to use the others. just need to ensure you get the correct deps manually and dependency issues are the most common problem people run into
~/d/c/lambda (licence-panel)> shadow-cljs compile local --verbose
shadow-cljs - server pid exists but server appears to be dead, proceeding without server.
shadow-cljs - config: /Users/colin/dev/cursive-site/lambda/shadow-cljs.edn cli version: 2.8.77 node: v12.1.0
[:local] Compiling ...
-> build target: :node-script stage: :configure
<- build target: :node-script stage: :configure (5 ms)
-> Resolving Module: :main
<- Resolving Module: :main (43 ms)
-> build target: :node-script stage: :compile-prepare
<- build target: :node-script stage: :compile-prepare (0 ms)
-> Closure JS Cache read: 63 JS files
<- Closure JS Cache read: 63 JS files (87 ms)
-> Cache read: cljs/core.cljs
<- Cache read: cljs/core.cljs (73 ms)
-> Cache read: clojure/string.cljs
-> Cache read: cljs/tools/reader/impl/inspect.cljs
-> Cache read: applied_science/js_interop/impl.cljs
<- Cache read: cljs/tools/reader/impl/inspect.cljs (34 ms)
<- Cache read: applied_science/js_interop/impl.cljs (178 ms)
<- Cache read: clojure/string.cljs (178 ms)
-> Cache read: cljs/tools/reader/impl/utils.cljs
-> Cache read: applied_science/js_interop.cljs
<- Cache read: cljs/tools/reader/impl/utils.cljs (6 ms)
-> Cache read: cljs/nodejs.cljs
<- Cache read: applied_science/js_interop.cljs (9 ms)
-> Cache read: lambda/credentials.cljs
<- Cache read: cljs/nodejs.cljs (5 ms)
-> Cache read: promesa/protocols.cljc
-> Cache read: cljs/tools/reader/reader_types.cljs
<- Cache read: lambda/credentials.cljs (6 ms)
-> Cache read: promesa/util.cljc
<- Cache read: promesa/protocols.cljc (7 ms)
<- Cache read: cljs/tools/reader/reader_types.cljs (8 ms)
<- Cache read: promesa/util.cljc (6 ms)
-> Cache read: cljs/tools/reader/impl/errors.cljs
-> Cache read: promesa/exec.cljc
<- Cache read: promesa/exec.cljc (6 ms)
-> Cache read: cljs_bean/from/cljs/core.cljs
<- Cache read: cljs/tools/reader/impl/errors.cljs (8 ms)
-> Cache read: promesa/impl.cljc
-> Cache read: cljs/tools/reader/impl/commons.cljs
<- Cache read: cljs_bean/from/cljs/core.cljs (6 ms)
-> Cache read: cljs_bean/core.cljs
<- Cache read: promesa/impl.cljc (6 ms)
-> Cache read: lambda/licence.cljs
<- Cache read: cljs/tools/reader/impl/commons.cljs (6 ms)
-> Cache read: clojure/set.cljs
-> Cache read: promesa/core.cljc
<- Cache read: cljs_bean/core.cljs (7 ms)
-> Cache read: lambda/dynamo/util.cljs
<- Cache read: lambda/licence.cljs (6 ms)
-> Cache read: clojure/walk.cljs
-> Cache read: cljs/tools/reader.cljs
<- Cache read: clojure/set.cljs (6 ms)
<- Cache read: lambda/dynamo/util.cljs (7 ms)
<- Cache read: promesa/core.cljc (459 ms)
-> Cache read: lambda/util.cljs
<- Cache read: cljs/tools/reader.cljs (466 ms)
<- Cache read: clojure/walk.cljs (467 ms)
<- Cache read: lambda/util.cljs (7 ms)
-> Cache read: cljs/tools/reader/edn.cljs
-> Cache read: lambda/dynamo/expr.cljs
-> Cache read: lambda/dynamo/response.cljs
-> Cache read: lambda/pricing.cljs
<- Cache read: cljs/tools/reader/edn.cljs (10 ms)
<- Cache read: lambda/dynamo/expr.cljs (9 ms)
-> Cache read: cljs_time/internal/core.cljs
<- Cache read: lambda/pricing.cljs (8 ms)
<- Cache read: lambda/dynamo/response.cljs (10 ms)
-> Cache read: cljs/reader.cljs
-> Cache read: lambda/dynamo/request.cljs
<- Cache read: cljs_time/internal/core.cljs (7 ms)
-> Cache read: cljs_time/core.cljs
<- Cache read: cljs_time/core.cljs (15 ms)
<- Cache read: lambda/dynamo/request.cljs (21 ms)
<- Cache read: cljs/reader.cljs (23 ms)
-> Cache read: lambda/kms.cljs
-> Cache read: lambda/email.cljs
-> Cache read: lambda/dynamo.cljs
-> Cache read: cljs_time/format.cljs
<- Cache read: lambda/kms.cljs (7 ms)
-> Cache read: clojure/edn.cljs
<- Cache read: lambda/email.cljs (10 ms)
<- Cache read: lambda/dynamo.cljs (10 ms)
-> Cache read: hiccups/runtime.cljs
-> Cache read: lambda/buy.cljs
<- Cache read: clojure/edn.cljs (10 ms)
<- Cache read: hiccups/runtime.cljs (8 ms)
<- Cache read: cljs_time/format.cljs (15 ms)
-> Cache read: lambda/webhook.cljs
-> Cache read: lambda/renew.cljs
-> Cache read: lambda/quote_email.cljs
<- Cache read: lambda/buy.cljs (11 ms)
-> Cache read: lambda/tables.cljs
-> Compile CLJS: lambda/email_content.cljs
-> Cache read: cljs_time/coerce.cljs
<- Cache read: lambda/tables.cljs (13 ms)
<- Cache read: lambda/renew.cljs (183 ms)
<- Cache read: cljs_time/coerce.cljs (181 ms)
<- Cache read: lambda/webhook.cljs (185 ms)
<- Cache read: lambda/quote_email.cljs (184 ms)
-> Cache read: lambda/quote.cljs
<- Cache read: lambda/quote.cljs (13 ms)
quote.cljs
hasn’t changed, I’d suspect email_content.cljs
the most, but that seems to have compiled ok.
there is a guard on the thread pool. in case it makes no progress for 30sec it should abort
No, no timeout after 30 seconds, and it Activity Monitor is still showing the Java process using CPU.
Yeah, I have some problem with a macro there - I should be able to track that down, thanks!
If someone is using shadow-cljs + deps, what's the normal way to package something as a library?
Everything you can imagine of every kind of dependency. It's just an uberjar. So it has compiled clj .class files etc.
I assume there must be common ways people do this stuff, but this deployment piece of the deps ecosystem sucks a little bit.
Maybe I'm answering the wrong question - I have the impression that the cljs library should just literally contain the .cljs files (or .cljc) as well as its dependency info.
Ya, like if you're packaging your cljs/cljc files for other shadow-cljs projects to use. I've been using pack.pack-alpha
for that
;; jar creation from juxt
:pack {:extra-deps {pack/pack.alpha {:git/url ""
:sha "d9023b24c3d589ba6ebc66c5a25c0826ed28ead5"}}
:main-opts ["-m" "mach.pack.alpha.skinny" "--no-libs" "--project-path" "api-cljs.jar"]}
(but this is not an uberjar)
and possibly you can share your .cljs/cljc files via :git/url
and not use a jar at all.
@slimslenderslacks Thank you - I just happened to run across a cljs library packaged just like that. Awesome!
Ya, it's quite nice when you first realize that you might not need a jar at all - strange feeling
Yeah that is blowing my mind a little bit. I still can't quite wrap my head around it.
I think it's kind of "don't make an uber jar"
I wonder what I'm doing wrong. Pack worked perfectly fine (I think) but when I run shadow-cljs and depend on these things directly (whereas before I was using them as local artifacts) I get a bunch of provide conflicts.
So I think the problem was, pack was including my old js build products. However, when I clean those up and make a new minimal jar, shadow-cljs can't find the classes in it, or says effectively "required namespace x.y.z is not available".
@pmooser I don't know anything about pack
or anything deps.edn
packaging related for that matter. I just use lein
since it is by far the easiest and straightforward.
you .jar file should only contain the relevant sources. you can check via jar -tvf your.jar
whats in it.
Yes, I understand, I don't use lein anymore, but what I'm a little more interested in is, how would you debug the issue of shadow-cljs saying something isn't available? I can unpack the jar
and look in it ... what does shadow-cljs expect to see, for just a normal cljs library? What directory layout?
Yeah, my namespace hierarchy is basically foo.bar.baz/file.cljs
and if unpack the jar, I see directories foo/bar/baz/file.cljs
...
I'm just not sure if there's something else or another level of structure that shadow-cljs expects to see, or what.
please give concrete examples ... the filename must match the ns ... that is it. like any other clojure(script) lib or tool. nothing special regarding shadow-cljs.
The required namespace "jett.hyperbase.client" is not available, it was required by "jett/hypercell/actions.cljs".
0 Wed Jul 08 18:49:46 CEST 2020 jett/hyperbase/
0 Wed Jul 08 18:49:46 CEST 2020 jett/
11489 Fri Jun 26 00:13:24 CEST 2020 jett/hyperbase/core.clj
484 Mon May 04 11:56:40 CEST 2020 jett/hyperbase/transit.clj
378 Mon May 18 19:47:00 CEST 2020 dev.clj
5419 Fri Jun 05 11:57:08 CEST 2020 jett/hyperbase/order_util.cljc
6375 Tue Jun 02 09:44:34 CEST 2020 jett/hyperbase/id_util.cljc
0 Wed Jul 08 18:49:46 CEST 2020 jett/gavel/
1612 Fri May 08 13:05:20 CEST 2020 jett/gavel/core.cljs
5526 Thu Jun 11 13:06:34 CEST 2020 jett/gavel/message_center.cljs
10888 Mon Jun 08 19:26:02 CEST 2020 jett/hyperbase/sample_application.cljs
549 Mon Apr 20 10:26:56 CEST 2020 jett/hyperbase/diff.cljs
403 Mon Jun 08 19:25:30 CEST 2020 jett/hyperbase/util.cljs
21608 Mon Jul 06 15:47:08 CEST 2020 jett/hyperbase/itom.cljs
16470 Fri Jun 26 14:36:42 CEST 2020 jett/hyperbase/client.cljs
979 Wed Jun 17 12:20:18 CEST 2020 jett/hyperbase/ui.cljs
5338 Tue Jun 09 13:00:06 CEST 2020 jett/hyperbase/core.cljs
576 Wed May 13 12:14:12 CEST 2020 jett/hyperbase/user.cljs
0 Wed Jul 08 18:49:46 CEST 2020 web/
240 Tue Apr 07 17:34:08 CEST 2020 web/index.html
0 Wed Jul 08 18:49:46 CEST 2020 web/css/
7313 Mon May 18 12:06:08 CEST 2020 web/css/site.css
ok the dev.clj
and web/
files probably shouldn't be in there but otherwise the file seems to be present?
Yes, I knew the web
and dev
things aren't useful but I couldn't figure out how they would be harmful.
In any case, it sounds like from your point of view, it looks correctly structured, so I'm not sure we should take more of your time trying to figure it out.
yeah but thats not shadow-cljs trying to find it. thats the JVM. so something is wrong with either your dependency on being on the classpath or the .jar itself
I don't see any manifest information in the jar, but I'm not sure what exactly is supposed to be there.
I'm not doing anything especially weird with pack
, but maybe there's another argument I'm supposed to use. And to be clear, I don't care about pack
. I just am trying to figure out the right way to package a cljs library using deps. We used to do this with lein trivially all the time and deploy to an internal maven server. I just can't quite figure out how to build an artifact with deps that works along with shadow-cljs.
all I can say is ... just use lein. even if its just to bundle stuff. I cannot help you with anything deps.edn related since I have not used anything.
shadow-cljs requires absolutely nothing special from the bundling and is not involved in it in any way
whatever you are doing is also wrong with any other tool. it has nothing to do with shadow-cljs.
For packaging a library, there aren't even supposed to be any build products from shadow-cljs or anything in it right?
for my libs, I do use lein just for that. I would reach out to whatever deps.edn script you’re using if you want help with releasing a CLJS lib
hey @pmooser, did you deploy that jar to clojars or something? Or are you depending on it using something like {:local/root "/path/to/your.jar"}
? Your setup sounds the same as mine so I'm also really wondering what's going wrong 🙂
certainly not a bad idea to switch to lein, but in my experience, what you're trying to do does work. There was no pom.xml in the unpacked jar. So it doesn't have any transitive dependencies?
Sorry it took me a bit to respond to this. So I got it working with lein - I'm deploying to an internal maven repository - and I don't quite understand why pack.alpha
doesn't have any manifest information.
So that seems to be the fundamental problem - the code is all included, but nothing about about to find the code or map it to source directories, etc.
To be honest, I'm not very expert at maven or any build tools - I mostly haven't had to be, using leiningen for a decade - so I'm not quite sure what pack is doing. I'd like to figure it out, though, and if I do, I will certainly keep you updated.
@pmooser Ya, I looked a bit more at my configuration, and the pom.xml really is a key component of how this works - I should've mentioned this to you when we first started this thread. This link is useful: https://github.com/juxt/pack.alpha#uploading-to-clojars-or-maven Part of the process involves keeping a pom.xml up to date (including updating the version in the pom.xml).