This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-24
Channels
- # adventofcode (2)
- # anglican (1)
- # announcements (4)
- # aws (2)
- # babashka (28)
- # beginners (18)
- # brompton (3)
- # calva (22)
- # clj-kondo (2)
- # cljdoc (29)
- # clojure (41)
- # clojure-europe (28)
- # clojure-gamedev (14)
- # clojure-nl (2)
- # clojure-spec (2)
- # clojure-sweden (1)
- # clojure-uk (6)
- # clojurescript (53)
- # css (3)
- # cursive (6)
- # duct (3)
- # emacs (5)
- # fulcro (29)
- # introduce-yourself (1)
- # liberator (5)
- # lsp (1)
- # malli (11)
- # meander (4)
- # nbb (11)
- # off-topic (17)
- # pathom (2)
- # polylith (8)
- # practicalli (1)
- # react (6)
- # reagent (11)
- # releases (2)
- # rewrite-clj (11)
- # shadow-cljs (59)
- # tools-deps (21)
- # vim (11)
@rberger this has nothing to do with shadow-cljs. it is code you are initializing during the build. assuming glogi, in a macro maybe. should go away if you add an actual slf4j impl to your classpath (logback, log4j, etc)
I suspect the only change regarding this concerning shadow-cljs is that previously some output may have been directed to other places. so the warning was there it just didn't show up.
Besides the warnings, It looks like none of the app logs are emitted when I am running shadow-cljs `2.15.4` or `2.15.5` , but runs fine with 2.15.3
I can assure you that nothing regarding this has changed in shadow-cljs for a very very long time. I setup jvm logging once and have not touched it since.
this is pretty much guaranteed to stem from glogi (or any other logging related thing you load)
Right, I assumed was some interaction between changes in shadow-cljs and glogi… I’ll ask the glogi folks if they know what’s up. At least I’m not blocked by it.
Can I do this with a shadow-cljs app? https://jupyterlab.readthedocs.io/en/1.2.x/developer/extension_dev.html#mime-renderer-extensions
i dont see why not – with the right config you can create a “npm/nodejs library” (as opposed to the browser-target bundle most projects use it for) • https://shadow-cljs.github.io/docs/UsersGuide.html#target-npm-module • https://shadow-cljs.github.io/docs/UsersGuide.html#target-node-library
there is no such thing as a shadow-cljs app. but yes shadow-cljs can produce code that you can load this way. best option most likely is :target :esm
. would help to have a plain JS example of an extension. then I could tell you exactly how it would look in shadow-cljs
ah this appears to be one https://github.com/jupyterlab/jupyterlab/tree/master/packages/pdf-extension
config is straightforward
{:target :esm
:output-dir "my-extension"
:modules {:main {:exports {default my.extension/default}}}}
(ns my.extension)
(def default
;; a JS object similar to
#js {})
don't know how exactly that default has to look for the extension to work but thats basic interop you definitely can express
I'm unsure how the extension will resolve dependencies though. do they need to be bundled or is that handled by jupyter? if so you need this extra config
{:target :esm
:output-dir "my-extension"
:modules {:main {:exports {default my.extension/default}}}
:js-options {:js-provider :import}}
:js-provider
tells shadow not to bundle anything and instead let the runtime provide it all (you need a very recent shadow-cljs version for all of this)
release
builds will likely just work. compile
and watch
will likely require adjustments since I don't know what jupyter does to the code and how possible it is to get a REPL into whatever it produces
Ah thanks. I'll meditate on that. I might need a slightly different type of extension, but probably will need to export an npm module either way. We'll see.
I'm trying to run tests for a :target :esm
build using :target :node-test
but it seems that compiles my tests not as an ecmascript module (which is not surprising) but how do I make that work together if I'm using esm features in the code which aren't available otherwise?
@borkdude doesn't exist currently. you could just make another :target :esm
build and configure it manually without the conveniences you get from :node-test
@thheller Ah right. What I did is make another module called :nbb_tests
within the same build. And then just run that file with node manually which executes the tests via the init fn
https://github.com/borkdude/nbb/blob/9b2ed912b6e8942dd599139e312ac3d4f0ba5b77/shadow-cljs.edn#L18
don't do that. make an extra build. you'll also need :compiler-options {:load-tests true}
. otherwise release
won't contain tests. might be what you want but I always recommend running tests in release
mode to rule out :advanced
causing issues 😛
yes, I noticed that, I do run tests after release but more like integration tests, invoking the main app with different use cases
so I should make an extra build but do I need to make a copy of the existing one and maintain everything in two places?
the problem with doing it in the main build is :advanced
. the tests likely will keep code alive that would otherwise be removed. it'll also make the nbb
package larger by however large your tests make everything. I doubt an end user will ever run them.
if you don't care about any of that keep it in your main build. otherwise a separate config with a dedicated :output-dir
would be best (IMHO)
will do that, but do I need to duplicate the config? this is no problem, just asking
I will make a Github Discussions topic for the ESM / CommonJS thing you reacted to on twitter, gotta run now
I don't know what your tests will do so I cannot answer how much of the config you need to duplicate
if the tests assume presence of certain module files then yes those you need to duplicate
I think I've found a more workable solution:
--aliases :test --config-merge shadow-tests.edn