shadow-cljs 2023-07-06 | Slack Archive

I want to disable reframe debug mode in dev and have this code

(def debug? ^boolean goog.DEBUG)

(when debug?
  (set! interop/debug-enabled? false))

works fine in dev but when doing a production build it fails with this error

Closure compilation failed with 1 errors
--- app/globals.cljs:8
@define re_frame.interop.debug_enabled_QMARK_ has already been set at re_frame/interop.cljs:13:17.

Any ideas how to get around this without having to remove that line whenever I want to do a build?

thheller12:07:11

it is already disabled by default for release builds?

thheller12:07:38

and its a closure-define, so you set it via https://shadow-cljs.github.io/docs/UsersGuide.html#closure-defines

thheller12:07:44

so not in code, but in the build config

thheller12:07:00

but as it is based on goog.DEGUG it'll already default to false in release

thheller12:07:16

oh nvm you want it in dev

thheller12:07:59

same deal though. you just set :dev {:closure-defines {re-frame.interop/debug-enabled? false}}

alexdavis12:07:45

That doesn't seem to work, setting it as a closure-define does not disable the debug mode in dev. And I'm still confused why the build fails with what I did above. debug? should be false when doing a release, and changing when debug? to when false lets the build succeed without issue

alexdavis12:07:56

This is how its set in the re-frame code https://github.com/day8/re-frame/blob/15a3e0e2f33141e2f930f85bd479494a3e75a6e9/src/re_frame/interop.cljs#L24

alexdavis12:07:51

~~well I guess i worked around it by making another closure-define called IS-DEV and doing (when IS-DEV (set! ... Still curious to know why I couldn't just use goog.DEBUG~~ Actually scratch that the prod build still fails with (when IS-DEV even though IS-DEV is definitely false for prod builds

Ben Lieberman13:07:54

Hey, I'm trying to use two packages from the Azure JS SDK: @azure/storage-queue and @azure/identity . I followed the steps for double bundling and I can use the former package (at least so far) without any errors. When I install @azure/identity and then compile and bundle, Webpack throws an error about there not being a child_process module, which I gather is a node thing. What confuses me is that both of these packages have what look to be similar package.jsons: https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/package.json and https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/storage/storage-queue/package.json. I tried adding these options to my shadow-cljs.edn

:js-options {:js-provider :external
                :entry-keys ["module" "browser" "main"]
                :external-index "target/index.js" 
                #_:external-index-format #_:esm}

with :external-index-format enabled and also commented out. @azure/storage-queue works both ways, and @azure/identity in neither case.

thheller15:07:26

can't really help you with webback issues. no clue about those packages either, maybe they are node only?

thheller15:07:52

:entry-keys has no effect when using :js-provider :external, but thats not really relevant to your issue

thheller15:07:08

child_process is a node built-in package, thats why I'm guessing you are including some node-only code?

Ben Lieberman15:07:01

Yeah I'll have to dig into the docs more. The storage lib explicitly identifies classes that are node only and includes instructions on bundling. But I haven't seen anything like that for identity yet. On the other hand, there's a class called InteractiveBrowserCredential?:man-shrugging:

Ben Lieberman16:07:22

I ditched Webpack for now. If I understand this section of the https://shadow-cljs.github.io/docs/UsersGuide.html#js-entry-keys right, it should look for "browser" in package.json first. But I get this output when I try to build

[:app] Build failure:
The required JS dependency "fs/promises" is not available, it was required by "node_modules/@azure/identity/dist/index.js".

Dependency Trace:
        bhlie/az_rather/app.cljs
        node_modules/@azure/identity/dist/index.js

If I'm reading that right, it's looking in the /dist/index.js of the @azure/identity package for the code it needs. But that is the dir specified in the "main" key of that package.json. I actually just got this to build successfully by specifiying

:js-options {:entry-keys ["browser" "module"]}}

but with this warning

Resource: node_modules/@azure/msal-browser/dist/interaction_client/PopupClient.js:519:5
 Parse error. extra @hidden tag

so I'm guessing this doesn't bode well.

Andrew Bowden16:07:09

So I am having an issue with shadow-cljs recognizing my npm package, I converted my cljs deps.edn project to javascript using shadow-cljs module target. The NPM package is published, and in our main project we are including it in our package.json. Then I build shadow-cljs and it completes the build, but when in the browser it says it can't find the modules from my npm package in the .node_modules. Any ideas?

thheller18:07:24

you are publishing a compiled cljs project to npm and then consume it in another cljs build?

thheller18:07:35

that is not supported and also quite pointless?

Andrew Bowden18:07:36

We were previously using sha's but we want to steer away from it. we considered using NPM or Maven to store our library and we do not want to use clojars. What's the best approach?

Andrew Bowden18:07:04

https://www.npmjs.com/package/black-hammer-lib above is our npm project https://www.npmjs.com/package/npm-playground-ng the bottom is my attempt to convert it to js run it as a npm package

Sagura09118:07:56

I am helping Andrew Bowden with this. I created the Black-hammer-lib. thinking we can use npm to call all the files and use it like how re-com and react do it

thheller18:07:01

whats wrong with clojars?

thheller18:07:25

so this is just uncompiled cljs sources?

Sagura09118:07:32

yes

Sagura09118:07:06

we cant have it public.

thheller18:07:14

npm is public?

Sagura09118:07:33

we can make the package private. we are just trying to find an alternitive.