Fork me on GitHub
Volodymyr Huzar13:03:17

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 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}}

Volodymyr Huzar18:03:20

@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

Volodymyr Huzar18:03:45

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


if you need multiple servers you just use multiple ports


:dev-http {3000 {:root "public" :ssl false} 3001 "something-else"}

Volodymyr Huzar18:03:29

by the way the latest release I see here is 2.11.13

Volodymyr Huzar18:03:17

thanks a lot! everything, works as expected now

👍 3

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"
 [{:type java.lang.NullPointerException
   :message "Cannot invoke \"Object.getClass()\" because \"target\" is null"
   :at [clojure.lang.Reflector invokeInstanceMethod "" 97]}]
 [[clojure.lang.Reflector invokeInstanceMethod "" 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 "" 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 "" 42]
  [clojure.lang.LazySeq seq "" 51]
  [clojure.lang.RT seq "" 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 "" 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 "" 137]
  [clojure.lang.Var applyTo "" 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 "" 137]
  [clojure.lang.Var applyTo "" 705]
  [clojure.main main "" 40]]}]



=== Version
jar:            2.11.25
cli:            2.11.25
deps:           1.3.2
config-version: 2.11.25


@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


oof why do I have shadow in my deps.edn AND package.json


well, that fixed it, was only upgrading the version in the package.json…


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?


define runtime error?


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.


well yeah, when I load the page the js should execute, should it not?


no, you should be using the lifecycle hooks provided for that


oh thanks so basically use one namespace on the production site that immediately executes and another with the lifecycle hooks while developing?


no, use :init-fn in your module to call the code you want to run on startup


ok well I'll read some more


as the blogpost explains


the pattern of swapping out namespaces in production is bad and absolutely advised against


yeah I only read the user guide and maybe I didn't understand that perfectly


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


leaving your code in an undefined state


makes a lot of sense, just didn't get that by myself 😄


thats why the error dialog doesn't go away


so much shit to learn when you're teaching yourself


really appreciate the help & quick reply ❤️


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

👌 3

@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


👍 understood :)


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