Fork me on GitHub
#shadow-cljs
<
2021-02-09
>
dazld12:02:48

hey there - I'm trying to understand what's happening with *print-fn* such that if I print something from a function in the browser, I'll see that output in my repl. I can see that *print-fn* appears to be bound to the same thing (?) in both the client and the repl, but the behaviour diverges.

dazld12:02:30

repl-print-fn it seems.. although I guess that's just the var

dazld12:02:45

I couldn't see anything in the docs about repl output too

dazld12:02:35

if I (prn :foo) from a connected repl, I see the output in the repl and the browser console, but if I do the same thing from a function (eg reagent component), then i only see it in the console.

thheller13:02:13

actually this is more or less a problem with nrepl and the nrepl clients

thheller13:02:27

if you use the plain shadow-cljs cljs-repl app then those prints should be captured

thheller13:02:53

it is just an artifact of most nrepl clients not accepting output that is not tied to a specific evaluation

thheller13:02:09

shadow-cljs does capture the prints, it just has nowhere to send them in case of nrepl

dazld16:02:17

and yep, i'm using an nrepl

dazld16:02:39

some kind of plumbing for a connected build would be pretty neat, getting prints back from the client

thheller13:02:25

shadow-cljs does not capture arbitrary prints outside the nREPL evaluation. pretty sure no CLJS REPL does

👍 3
roman01la13:02:24

Hello 👋 Is it expected that release build won't write into location specified in {:release {:output-to "..."}}?

thheller13:02:27

depends. which :target are you talking about? :output-to for example is not an option for :browser

roman01la13:02:40

:target :browser

thheller13:02:48

that should be :output-dir then

roman01la13:02:35

ah, so there's no way to specify output-dir per module?

thheller13:02:23

no, it is by design that all :modules should live in the same directory. otherwise complicates things with loader and source maps and so on

roman01la13:02:26

got it :thumbsup: what about compiler namespaces, are they written into :output-dir as well when running release?

thheller13:02:32

no, in case you mean the cljs-runtime dir you otherwise get with watch or compile output

roman01la13:02:44

perfect! thanks 🙏

roman01la14:02:15

btw, are there any docs on how shadow bundles NPM deps? is it using own bundler? does it split npm deps together with cljs splits?

thheller14:02:19

yes, yes, yes

thheller14:02:53

some other posts also talk about it

roman01la14:02:06

thanks! I have some more questions if you don't mind: what about DCE? does it exist, is it on par or better than webpack? what happens with NPM deps when compiling with advanced optimizations?

thheller14:02:28

for npm dependencies it does not exist no, they only go through :simple

thheller14:02:39

I might add it at some point but currently everything is pretty webpack specific so even other JS bundlers struggle with it

roman01la14:02:12

I see. So how's JS deps are included into cljs splits then? Does shadow splits NPM deps into modules based on requrie's from cljs code and then prepends JS splits to CLJS ones?

thheller14:02:36

basically yes

thheller14:02:52

but its file based not module based, so even if they are in the same package they might end up in different modules depends on how you use them

roman01la14:02:53

cool! thanks :thumbsup:

johnjelinek15:02:40

does anyone know of a reference architecture/starter kit for clojurescript that has typescript interop? Would this be interesting to anyone?

roman01la20:02:03

I got to code splitting and hitting an issue now: goog is not defined

roman01la20:02:49

the setup is simple: there's module A and module B that depends on A, when A is loading the exception is thrown

roman01la20:02:55

should mention it happens in release build with advanced optimizations

roman01la20:02:34

the line where it fails is goog=goog||{} which I guess comes from goog's base.js

thheller20:02:13

hmm? advanced shouldn't contain this?

roman01la20:02:11

hmm, good point, might be something coming from a library, let me see, thanks

roman01la20:02:15

here's code block around that line compiled with :pseudo-names true

$APP.$JSCompiler_stubMap$$ = [];
    goog = goog || {};
    $goog$global$$ = this || self;
    $goog$NONCE_PATTERN_$$ = /^[\w+/_-]+[=]{0,2}$/;
    $goog$cspNonce_$$ = null;
    $goog$UID_PROPERTY_$$ = "closure_uid_" + (1E9 * Math.random() >>> 0);
    $goog$uidCounter_$$ = 0;
    $APP.$goog$now$$ = Date.now || function() {
        return +new Date
    }
    ;
    $goog$evalWorksForGlobals_$$ = null;
    $APP.$goog$inherits$$($goog$debug$Error$$, Error);

roman01la20:02:49

is that something that shouldn't be there after advanced?

thheller20:02:22

not a clue where this is from. it shouldn't be there.

thheller20:02:35

which versions do you use? make sure it all matches properly. using mismatched closure compiler, CLJS or shadow-cljs versions causes all sorts of weird issues

roman01la20:02:46

shadow 2.10.21 cljs 1.10.773

thheller20:02:11

in a regular build it should be something like var da=da||{} or pseudo-named var $goog$$ = $goog$$ || {}

roman01la20:02:33

huh, actually I'm building using shadow from NPM of one version and requiring shadow's loader, which is coming from shadow of another version declared in deps.edn, should fix that as well

thheller20:02:21

yeah those should be somewhat close but only the deps.edn version is really relevant

thheller20:02:45

npm stuff only affects the shadow-cljs command line tools, nothing from the compilation

👍 3