not if its cached. if you have macros that have side effects you might need to disable cache completely. macros are not supposed to have side effects. https://shadow-cljs.github.io/docs/UsersGuide.html#_compiler_cache

Thanks heller. Those docs help, and yes, i assume we have macros with side effects.

cc @U04V15CAJ

Why does closure need to transpile anything if it's already es6?

yeah, that’s also a good question

uhm do not do this?

oh nvm. thought for a sec it was trying to compile the squint cljs output

update shadow-cljs I guess?

I’m on 2.20.20

hmm ok. then I guess it doesn't work

> to compile the squint cljs output yeah, that is what I origninally tried to do, and the squint output has imports to squint-cljs/core.js which produces the error above

do not ever include the output of a compiled CLJS lib via JS

that will only bring trouble and nightmares

squint produces normal JS, not CLJS

everything is "just es6" - imo closure should be able to handle this

but the squint-cljs lib contains compiled CLJS code

also, why is babel transform pass kicking in, also for the :esm target? What is the transformation doing?

@U05224H0W That is true, but squint-cljs/core.js is pure es6

ok

well the error is pretty clear. it uses code the closure compiler doesn't support

so there is nothing to do, except NOT having it process this code

which you do via :js-provider :import for :esm builds

ah ok, @U04V15CAJ I see you do that as well here: https://github.com/squint-cljs/squint/blob/c50c4c2582aeda9e874a867e19a2bfcfc9e4caab/shadow-cljs.edn#L4-L5 how would I make squint core functions available to the browser? According to: https://shadow-cljs.github.io/docs/UsersGuide.html#_third_party_tool_integration I need some extra tool to process shadow output

@U9EQP1K0X You could use another bundler on the final output, e.g. esbuild or so

npx esbuild public/main.js --bundle --minify --platform=browser --outfile=public/main2.js --format=esm

something like this

or for dev builds, include squint-cljs core.js yourself in the HTML

Here is a playground which also does that: https://squint-cljs.github.io/squint/

<script async src=""></script>
    <script type="importmap">
      {
        "imports": {
          "squint-cljs": "",
          "squint-cljs/core.js": "",
          "squint-cljs/string.js": ""
        }
      }
    </script>

cool thanks, now I’m using shadow to compile other NPM dependencies together with real cljs sources in the same project, how can I make :js-provider selective to just squint-cljs/core? Is that :resolve https://shadow-cljs.github.io/docs/UsersGuide.html#js-resolve?

If I remember correctly, you can also use:

:js-options {:keep-as-import #{"fs"}}

(replace fs with squint-cljs/core.js)

ah cool

or perhaps this is deprecated @U05224H0W? I don't see this option mentioned in the README

still exists yeah

ehm, with

:keep-as-import #{"squint-cljs/core.js"}

are you importing that file specifically?

it is really difficult to make any kind of suggestions without seeing any code

:keep-as-import #{"squint-cljs"}

or whatever you are requiring in your code

@U9EQP1K0X Perhaps you can make a tiny repro repository

like the exact name

yeah, I think I can go a bit further, and produce a repro repo if I am still stuck. Thanks a lot @U05224H0W @U04V15CAJ !

@U05224H0W Is there a way to run a tool like webpack or esbuild after shadow is done compiling in watch mode, to resolve the "keep-as-import" imports? Because the browser still needs to have those files. We could use import-maps for those and then serve those files manually, but that's also a bit tedious

no, that is not supported

@U9EQP1K0X figured it out by calling esbuild in a build hook

if its a build repl you can just put it into a ns an :preloads it?

Ah yes, that works perfectly. I somehow assumed preloads wouldn’t be a thing with node but I’m realizing I didn’t think about that very much otherwise I would have realized they probably work just the same 🙂

I find this unhandledRejection stuff sufficiently annoying that I’d love for it to be part of the shadow node repl by default somehow. I think it might also be quite confusing for newcomers because some REPL clients don’t report it very well when the underlying node process dies.

the trouble with this is that is can happen anywhere

so also in REPL internals, which may end up causing a infinite exception loop and burn your CPU to death 😛

so I'd rather not

Ah I see

Could the REPL catch errors of any promises that are coming through? (i.e. more explicit)

not sure. having looked at many node internals for many years

there might be better hooks nowadays

I mean more like it looks at whatever the user’s expression returns and adds a .catch -- probably I’m thinking too simplistic here 🙂

not sure thats a good idea

> not sure thats a good idea Assuming the mechanics are viable and the exception is still reported, I'm not sure how this could be super-harmful. It could be on-by-default in dev mode, with a preamble to the reported error that "if this was production mode, your Node process would crash here." Using tap> seems a bit iffy though, since then the problem goes unreported if there is no tap reporter is set up. Maybe default to just print, but allow switching to tap> in the config?

yeah totally, tap> is specific to my setup