> Namespaces that are known to include side-effecting macros can be blocked from caching. They won’t be cached themselves and namespaces requiring them will not be cached as well. The clara-rules library has side-effecting macros and is blocked by default. You can specify which namespaces to block globally via the :cache-blockers configuration. It expects a set of namespace symbols. @colinkahn @lilactown

(from the docs)

Not really having luck with :cache-blockers . I have: :cache-blockers #{cljs.spec.test.alpha clojure.spec.test.alpha}

@colinkahn there is already special support in the caching layer regarding specs so this shouldn't be necessary

are you doing anything special with those specs?

In Shadow, can builds specify their source paths, or are they always specified at the top-level? For example, if I have a test build and I want to include my test sources for that but not for my production build, can I do that?

shadow-cljs by default only includes files in a build that are actually required somewhere

so if your "production" build doesn't require any of the tests then it won't be in the build

Ok, great, thanks.

https://code.thheller.com/blog/shadow-cljs/2018/02/08/problem-solved-source-paths.html

but no there are no separate source paths per build

Ok, as long as I don’t actually need them that’s ok.

you can always use deps.edn or project.clj to sort of get that but in regular use it shouldn't be required

No, as long as I know that this is the idiomatic solution I’m fine with that.

@thheller Hi Thomas, anything new about React-native and the websocket management ? Follow up your first pass about this the last summer ? > first pass to properly handle react-native not closing websockets

I added a few REPL helper fns but nothing automated yet

dunno how ... the react-native issue I opened was closed due to inactivity and nobody ever looked at it

IMHO its a react-native bug and I hate working arround other peoples bugs

I added (shadow.cljs.devtools.api/repl-runtimes-clear) to kick out "stale" sessions

but funny enough .. the react-native websockets sometimes keep responding

> dunno how ... the react-native issue I opened was closed due to inactivity and nobody ever looked at it Yes, I see this 😖

so they never go stale although the app was reloaded ...

I don't do any react-native development myself so I never dug into it deeper

Thx for the information ! I will try about (shadow.cljs.devtools.api/repl-runtimes-clear)

> IMHO its a react-native bug and I hate working arround other peoples bugs Totally, I understand you

I'm having trouble using shadow-cljs, requiring a JS file that requires lodash. For example, if I have the following line on src/dependent.js:

import { size, isEqual } from 'lodash';

(ns lod.main
  (:require ["/dependent" :as d]))

It fails with:

Closure compilation failed with 2 errors
--- dependent.js:1
Requested module does not have an export "isEqual".
--- dependent.js:1
Requested module does not have an export "size".

Is this a known issue?

the issue is known yes. the closure compiler only really supports "strict" mode ESM interop so it complains when its fed commonjs code

support works a bit better when using require and module.exports so CommonJS instead of ESM

but that has other issues ... so doesn't work too well in other areas, mostly around requiring CLJS code from JS