Hey, I’m a relatively new clojurian. I got my own stuff working by adding

:compiler-options {:optimizations :simple}

(fn [data]
                                     (let [integer-value (.. data -datum -rpn)]
                                       (cond
                                         (> integer-value first-threshold)) "#c43a31"
                                         (> integer-value second-threshold) "#ffa500"
                                         :else "#00ff00")))

shadow-cljs release main

@koivistoinen.tuomas turn on :infer-externs :auto https://shadow-cljs.github.io/docs/UsersGuide.html#externs that will likely give you a warning about the (data -datum -rpn). so you ^js data whereever that is coming from and that should fix it.

does :exclusions works on shadow? I'm trying to use a custom version of test.check that I built (on my group name), but because there is some dep trying to load the original test.check they are conflicting, I tried put :exclusions [org.clojure/test.check] in every dep a I have, but that didn't worked (I'm using :dependencies from shadow itself in this project), is there a way around it?

should work? [some-dep "version" :exclusions [foo/bar]?

oh wait. shadow-cljs itself has a dependency on test.check because of pathom

so thats probably where it is coming from

https://github.com/thheller/shadow-cljs/blob/1d6c44140d60a4fc15aace86138fa39e7dfd7f8a/project.clj#L63-L70

can't remember the details. maybe thats not current anymore?

humm, pathom should not need that unless you are doing generative stuff with it

my case is a bit specific due to I need to use a custom version of test.check that I forked, and this project so far needs to use shadow, I could get shadow to use my version by releasing with a bigger version number, but now getting a lot of warnings due to duplication of namespaces on classpath

those should be gone with newer versions? it doesn't scan the classpath for cljs sources anymore?

@wilkerlucio just tested, pathom won't start without test.check on the classpath.

ok, I can check that, this shouldn't be required

https://github.com/edn-query-language/eql/blob/master/src/edn_query_language/core.cljc#L4

fails because of that

ok, updating it in a bit

thanks for the precise pointing 🙂

@thheller eql 1.0.0 now has generative features on a different ns, pathom 2.3.0-alpha9 bumps EQL, that should fix it

just a thought but you could maybe move all the spec stuff into a separate ns. then people can add eqn-query-language.specs to :preloads if wanted. you can get rid of the goog-define that way. right now I doubt that most people are aware of the INCLUDE_SPECS define?

its just dev-only stuff anyways

makes sense, I think I'll move on this direction next

I also thought about making that a bit automatic in shadow-cljs. so you can set :include-specs true or so and it auto includes foo.bar-specs in development if foo.bar is part of the build

since dev-only specs are hard to keep out of the main build otherwise currently

the main problem there I think is that its hard to know if a spec is intended for prod or not, because some are

in recent projects I've been using guardrails, with that I use the guardrails fn to define dev stuff, and spec directly for prod stuff, this way at least its a clean separation

well prod specs you'd just include normally

ah, sorry, I think I understand now

about a pattern to auto-require *-specs during dev

yeah. like now pathom includes edn-query-language.core. with the flag shadow-cljs would detect edn-query-language.core-specs and also include that automatically in dev

good thing about that way is that the specs can directly include the core ns and use it as a alias and easily do fdef for it

if core would require core-specs that not easily possible because of the circular reference

but yeah guardrails is much more involved so that wouldn't work

last time I checked just including guardrails did leave some stuff after :advanced even if never used

was that a long time ago? I know tony made some changes to just inject validation code instead of rely on instrumentation, I wonder if that makes the difference on it

I added https://github.com/day8/re-frame-debux#option-2-namespace-aliases-with-shadow-cljs as an alternative for things like that

so you can actually ensure that nothing is left

nice

its been a while yes

but maybe that wouldn't work for guardrails, given I still need guardrails in prod to generate the standard fns

yeah, your alias ns would do exactly that

ah, ok, not a transparent stub thing, cool

the tracing stuff does that too. without the alias it adds the tracing code. with the alias it just does a regular defn

what tracing stuff?

re-frame example from above

https://github.com/day8/re-frame-debux/blob/master/src/day8/re_frame/tracing_stubs.cljc

the issue why we need this is that even if you have a macro that does nothing

you cannot get rid of the ns requires the namespace providing the macros has

https://github.com/day8/re-frame-debux/blob/master/src/day8/re_frame/tracing.cljc#L1-L11

and those may do stuff that don't play well with :advanced

hey, is there a way to tell shadow-cljs to not generate a huge index.js for debug builds, instead going for document.write('<script...>') like vanilla cljs tooling?

case in point: I have a react-native app and RN insists on reloading the whole thing every time I change something, even though RN's fast refresh is turned on

@dj942 for :browser there is an option to emit multiple files. for react-native there is not.

last time I checked there were 2 options for turning of reload in RN. with both off it would only check the generated shadow-cljs output when loading the app but never while its running

I don't event mind longish reloads all that much, but I'd prefer not to lose app state every time a reload happens

sounds to me like you are letting react-native reload stuff

shadow-cljs reload would keep your state

yeah, that's correct

I guess I need to read up metro bundler's documentation on how to disable reload

I never configured anything in metro

just the debug menu thing in the app itself

fast refresh and live-reload or whatever the other one is called

there are two options

looks like there's only one in react-native 0.62, "disable fast refresh"

no clue, last time I checked there were 2 options

can't remember which version that was though

it works! although it doesn't trigger a rerender after reload

I guess there's a callback somewhere

that part is up to you, the demo repo I created has an example of how you can set that up

glorious

huge thanks

2.9.9 looks to have introduced a regression with regard to deps.cljs and a package.json file

IllegalArgumentException: No matching field found: exist for class .File
        clojure.lang.Reflector.getInstanceField (Reflector.java:397)
        clojure.lang.Reflector.invokeNoArgInstanceMember (Reflector.java:440)
        shadow.cljs.devtools.server.npm-deps/install-deps (npm_deps.clj:160)
        shadow.cljs.devtools.server.npm-deps/install-deps (npm_deps.clj:131)
        shadow.cljs.devtools.server.npm-deps/main (npm_deps.clj:242)
        shadow.cljs.devtools.server.npm-deps/main (npm_deps.clj:228)
        shadow.cljs.devtools.cli-actual/main (cli_actual.clj:141)
        shadow.cljs.devtools.cli-actual/main (cli_actual.clj:132)
        clojure.core/apply (core.clj:669)
        clojure.core/apply (core.clj:660)
        shadow.cljs.devtools.cli-actual/-main (cli_actual.clj:219)
        shadow.cljs.devtools.cli-actual/-main (cli_actual.clj:217)
        clojure.lang.Var.applyTo (Var.java:705)
        clojure.core/apply (core.clj:665)
        clojure.core/apply (core.clj:660)
        shadow.cljs.devtools.cli/-main (cli.clj:75)
        shadow.cljs.devtools.cli/-main (cli.clj:67)
        clojure.lang.Var.applyTo (Var.java:705)
        clojure.core/apply (core.clj:665)
        clojure.main/main-opt (main.clj:514)
        clojure.main/main-opt (main.clj:510)
        clojure.main/main (main.clj:664)
        clojure.main/main (main.clj:616)
        clojure.lang.Var.applyTo (Var.java:705)
        clojure.main.main (main.java:40)

Dropping back to 2.9.8 and it works

whoops.

exist vs exists?

yeah, fixed in 2.9.10

Thanks

Hi, I am trying to build a small HTTP server in NodeJS. I am trying to use macchiato, but after requiring the dependency [macchiato.server :as http], I get the following error on startup:

SHADOW import error C:\Shared\orgpad\.shadow-cljs\builds\preview\dev\out\cljs-runtime\shadow.js.shim.module$xregexp.js
Error: Cannot find module 'xregexp'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15)
    at Function.Module._load (internal/modules/cjs/loader.js:508:25)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:22:18)
    at C:\Shared\orgpad\.shadow-cljs\builds\preview\dev\out\cljs-runtime\shadow.js.shim.module$xregexp.js:3:33
    at global.SHADOW_IMPORT (C:\Shared\orgpad\preview\preview.js:64:44)
    at C:\Shared\orgpad\preview\preview.js:2329:1
    at Object.<anonymous> (C:\Shared\orgpad\preview\preview.js:2342:3)
    at Module._compile (internal/modules/cjs/loader.js:701:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)

thats the node message for a missing npm install xregexp?

cool, it works, thx

what is the approach for hot code reloading? stopping the server and starting it again?

no clue. I've never used macchiato

Is is possible to run shadow-cljs watch on a build without injecting nREPL related things into the output? I’m using the :node-script target and have a coworker who doesn’t use a REPL (I know, I’ve tried to convince him), but would still like to have the auto-compile functionality of the watch whenever the file is changed.

> The nREPL server can be disabled by setting :nrepl false

wait, what do you mean injecting nrepl?

@cjsauer there are no nrepl related things injected into the JS output, it just connects the websocket which handles hot-reload and also the REPL

so its all the same websocket anyways, nothing to turn off

Ah ok. That is what prevents the development node script from exiting yea? In a normal workflow, I’d run node my_script.js and then connect my REPL. In his case tho, he’d like to run the script manually upon every change, and have it exit normally.

you can set :devtools {:enabled false} in the build. then it won't connect and just exit

Cool, that’s what I’m after :thumbsup:

general question I guess: I'm thinking about allowing a shadow-cljs.local.edn or so which could override shadow-cljs.edn config stuff

seems like quite often people have different preferences when working in teams, so that way each user could have their own local config

I really dislike using env vars to stuff like that

I’m having exactly this conversation with my coworker at the moment (he just asked me how to read env vars in shadow-cljs.edn). A local config file would be great for things like this.

like you could keep devtools while your coworker can disable it 😛

shadow-cljs watch the-script --config-merge "{:devtools {:enabled false}}" also works though

Ooh that’s nice, didn’t know that. I was considering having two builds: :script-calvin and :script-eric haha

hehe that also works 😛

I appreciate your help and hard work @thheller. Thanks for the guidance.