Fork me on GitHub
#shadow-cljs
<
2021-08-24
>
thheller05:08:41

@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)

thheller05:08:55

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.

rberger05:08:52

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

rberger05:08:12

Let me confirm that

rberger05:08:30

I was incorrect. I still get logs, so its just the warnings then… Thanks

thheller05:08:29

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.

thheller05:08:50

this is pretty much guaranteed to stem from glogi (or any other logging related thing you load)

thheller05:08:29

I looked at glogi and it appears to load pedestal log in a macro namespace

thheller05:08:36

that in turn uses slf4j

thheller05:08:10

if you use that namespace that is the cause of the warnings

rberger05:08:11

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.

thheller05:08:12

might be fine to just add a logging lib to your dependencies

thheller05:08:30

or might require an actual logging config file

rberger05:08:55

Heh, whole point of using that library is to ignore all that stuff 😉

rberger05:08:45

PTSD from the logging wars

thheller05:08:51

you can try shadow-cljs browser-repl

thheller05:08:18

and then (require 'lambdaisland.glogc) to see if the warnings show up

thheller05:08:29

although browser-repl might hide it somewhere

thheller05:08:43

maybe best shadow-cljs server and then separately shadow-cljs browser-repl

thheller05:08:33

glogi itself seems to be fine, just the glogc requires pedestal

rberger05:08:49

Ok, appreciate the pointers!

eins7815:08:34

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-modulehttps://shadow-cljs.github.io/docs/UsersGuide.html#target-node-library

thheller16:08:05

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

thheller16:08:04

as someone who has never done anything with jupyter: how easy is it to install? 😛

thheller17:08:33

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

thheller17:08:02

don't know how exactly that default has to look for the extension to work but thats basic interop you definitely can express

thheller17:08:08

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

thheller17:08:24

: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)

thheller17:08:09

then in the :output-dir you need a package.json with "main":"./main.js"

thheller17:08:10

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

thheller17:08:35

compile may just work too though, really depends on what it does

Pepijn de Vos17:08:40

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.

borkdude14:08:26

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?

thheller16:08:17

@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

borkdude17:08:51

@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

thheller17:08:58

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 😛

borkdude17:08:54

yes, I noticed that, I do run tests after release but more like integration tests, invoking the main app with different use cases

borkdude17:08:15

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?

thheller17:08:29

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.

thheller17:08:38

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)

borkdude17:08:44

will do that, but do I need to duplicate the config? this is no problem, just asking

borkdude17:08:52

thanks a lot

borkdude17:08:18

I will make a Github Discussions topic for the ESM / CommonJS thing you reacted to on twitter, gotta run now

thheller17:08:04

I don't know what your tests will do so I cannot answer how much of the config you need to duplicate

thheller17:08:27

if the tests assume presence of certain module files then yes those you need to duplicate

borkdude20:08:23

yes, I want to test the modules exactly like in the production build

borkdude20:08:37

I think I've found a more workable solution:

--aliases :test --config-merge shadow-tests.edn

borkdude16:08:20

This turned out to work really well @thheller

thheller16:08:29

not what I would have done but sure that works 😛

borkdude16:08:24

what would you have done, copy everything?

thheller16:08:21

hard to say since I don't know exactly what you are testing. likely I would just test namespaces directly without the whole modules business. but if thats exactly what you are testing I would have most likely copied the config yeah

thheller16:08:46

you could go with :build-defaults {...} or :target-defaults {:esm {...}} too

thheller16:08:01

as a way to configure stuff for multiple builds

borkdude17:08:10

nice, thanks

lilactown23:08:14

I have a few namespaces that I only use from a REPL. if I change and save them, they get hot reloaded, and I can no longer reference them anymore from the REPL and have to restart my watch