This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-26
Channels
- # announcements (3)
- # architecture (53)
- # babashka (6)
- # beginners (101)
- # bitcoin (3)
- # calva (4)
- # cider (3)
- # clara (7)
- # cljdoc (2)
- # cljsrn (14)
- # clojure (104)
- # clojure-europe (96)
- # clojure-germany (21)
- # clojure-nl (6)
- # clojure-serbia (3)
- # clojure-spain (1)
- # clojure-uk (13)
- # clojuredesign-podcast (4)
- # clojurescript (14)
- # cursive (5)
- # data-science (19)
- # datomic (16)
- # emacs (15)
- # fulcro (33)
- # graalvm (5)
- # honeysql (3)
- # instaparse (2)
- # jobs (3)
- # lsp (82)
- # malli (2)
- # off-topic (11)
- # pedestal (4)
- # polylith (62)
- # practicalli (4)
- # shadow-cljs (56)
- # tools-deps (53)
- # vim (17)
- # xtdb (53)
We have :ssl
in our configuration which enabling https for all builds. Is it possible to run :devtools
for one of the build on http?
To add more context: I am trying to run tests using https://github.com/lambdaisland/kaocha-cljs2 and having https there adding a lot of overhead to setup all the tools to have proper certificates provided everywhere. Also Chrome complains with registering custom ServiceWorkers when self signed certificates are used which seems to be configurable but again adds another overhead.
@vguzar in 2.11.26
I added an option to allow that. :dev-http {3000 {:root "public" :ssl false}}
@U05224H0W seems it will not fix a problem I have. A :dev-http
is a global configuration, isn’t? What I need to run one of the builds (test one) on http, but I want application build still to be run using https. Is it possible to solve somehow, maybe disable ssl using :devtools
configuration?
the http servers are ALWAYS global, the :devtools
:http-root
and :http-port
are old configuration and were replaced by :dev-http
so if you previously had :devtools {:http-port 3000 :http-root "public"}
that should instead be :dev-http {3000 "public"}
or the the example above with the disabled :ssl
oh, good to know that, doesn’t it complicates the things? how to serve different roots for different builds now?
no, it makes things much simpler. it was my mistake allowing the devtools http config in a config for the build. that was never how it worked and the dev-http matches more closely how it actually works
oh, got it
by the way the latest release I see here https://github.com/thheller/shadow-cljs/releases is 2.11.13
apologies… but has anyone run into this? I’m dusting off a project that hasn’t been touched in like a year
[:failed-to-compare "^16.13.1" "16.9.0" #error {
:cause "Cannot invoke \"Object.getClass()\" because \"target\" is null"
:via
[{:type java.lang.NullPointerException
:message "Cannot invoke \"Object.getClass()\" because \"target\" is null"
:at [clojure.lang.Reflector invokeInstanceMethod "Reflector.java" 97]}]
:trace
[[clojure.lang.Reflector invokeInstanceMethod "Reflector.java" 97]
[shadow.cljs.devtools.server.npm_deps$make_engine invokeStatic "npm_deps.clj" 39]
[shadow.cljs.devtools.server.npm_deps$make_engine invoke "npm_deps.clj" 32]
[shadow.cljs.devtools.server.npm_deps$fn__17458$fn__17459 invoke "npm_deps.clj" 46]
[clojure.lang.Delay deref "Delay.java" 42]
[clojure.core$deref invokeStatic "core.clj" 2320]
[clojure.core$deref invoke "core.clj" 2306]
[shadow.cljs.devtools.server.npm_deps$fn__17458$fn__17461 invoke "npm_deps.clj" 52]
[shadow.cljs.devtools.server.npm_deps$is_installed_QMARK_ invokeStatic "npm_deps.clj" 207]
[shadow.cljs.devtools.server.npm_deps$is_installed_QMARK_ invoke "npm_deps.clj" 201]
[shadow.cljs.devtools.server.npm_deps$main$fn__17546 invoke "npm_deps.clj" 223]
[clojure.core$complement$fn__5669 invoke "core.clj" 1441]
[clojure.core$filter$fn__5893 invoke "core.clj" 2821]
[clojure.lang.LazySeq sval "LazySeq.java" 42]
[clojure.lang.LazySeq seq "LazySeq.java" 51]
[clojure.lang.RT seq "RT.java" 535]
[clojure.core$seq__5402 invokeStatic "core.clj" 137]
[clojure.core$seq__5402 invoke "core.clj" 137]
[shadow.cljs.devtools.server.npm_deps$main invokeStatic "npm_deps.clj" 225]
[shadow.cljs.devtools.server.npm_deps$main invoke "npm_deps.clj" 216]
[shadow.cljs.devtools.cli$main invokeStatic "cli.clj" 143]
[shadow.cljs.devtools.cli$main doInvoke "cli.clj" 134]
[clojure.lang.RestFn applyTo "RestFn.java" 137]
[clojure.core$apply invokeStatic "core.clj" 669]
[clojure.core$apply invoke "core.clj" 660]
[shadow.cljs.devtools.cli$_main invokeStatic "cli.clj" 221]
[shadow.cljs.devtools.cli$_main doInvoke "cli.clj" 219]
[clojure.lang.RestFn applyTo "RestFn.java" 137]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.core$apply invokeStatic "core.clj" 665]
[clojure.main$main_opt invokeStatic "main.clj" 514]
[clojure.main$main_opt invoke "main.clj" 510]
[clojure.main$main invokeStatic "main.clj" 664]
[clojure.main$main doInvoke "main.clj" 616]
[clojure.lang.RestFn applyTo "RestFn.java" 137]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.main main "main.java" 40]]}]
@haywood looks like you upgraded to java JDK 15+ in the meantime? that removed the Nashorn JS engine previously used. need to upgrade shadow-cljs.
the above versions would have the fix but you might be using deps.edn or project.clj to manage your dependencies so you'd need to upgrade shadow-cljs there
whenever I get some kind of runtime error during reload while developing, there's a small error dialog fixed at the bottom of the page. This does not disappear until I completely reload the page. Is that a bug or supposed to be like that?
I fix that, and the page reloads again and everything is fine, except that the error stays at the bottom
ok that looks like you are running code directly on load? (eg. directly calling (render)
) in your file? you should not be doing that.
no, you should be using the lifecycle hooks provided for that https://shadow-cljs.github.io/docs/UsersGuide.html#_hot_code_reload
https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html
oh thanks so basically use one namespace on the production site that immediately executes and another with the lifecycle hooks while developing?
the pattern of swapping out namespaces in production is bad and absolutely advised against
it seemed more like "you can do that if you want" not "you need to do that actually"
well the issue with running code directly on load is that it interrupts that reload cycle
shadow-cljs cannot know WHAT failed during load, it only knows that something failed and abort
yeah thats why shadow-cljs tries to keep everything as minimal as possible. unfortunately some older blogposts, tutorials, templates use more complex setups making things more complicated than they need to be. IMHO, YMMV 😛
yeah I'm not an inexperienced dev, only in clj/cljs... I so so love getting everything as simple as possible, which is basically what I've been doing so far. And shadow-cljs is a really nice piece of software in the simplicity area
@UCULU82G3 “as simple as possible” sounds like you’re on the good path 🙂
@U050KSS8M yeah over-engineering is very rampant where I'm from, took a bit to get to this path not easy when you're doing it alone and "only" trying to scour the interwebs for the "right things to do" - so much knowledge in people's heads but not written down I feel 😄
@UCULU82G3 “over-engineering” - what language/framework?
@U050KSS8M I more meant geographically/where I've been working/studying so far, Germany but language is Java/C#/JS mostly
Does anyone know of a good example of using a service worker with shadow-cljs?
(in terms of shadow-cljs.edn set up)
{:target :browser :modules {:sw {:init-fn my.sw/init :web-worker true}}}
should be ok
FWIW I think its better to use a dedicated tool for this like https://developers.google.com/web/tools/workbox