In case it's relevant, I use up to date ShadowCLJS with :target :esm.

Somewhere, something calls cljs.spec.test.alpha/instrument to instrument all the functions for which fdef was called. By itself, fdef doesn't validate anything, it just creates a spec. So I assume that you see the difference in behavior not in the CLJS vs JS scenario but rather in the development build vs production build scenario. In this case , it's very likely that something calls instrument only during the development build.

Hey @U2FRKM4TW. The difference is between compile time (CLJS code) vs. loading that compiled (JS) code in Deno.

What you say about instrument makes sense.

I wonder what's the recommended way to do the instrumentation? One way would be hooking :pre and :post, but I'm not sure whether that's a good pattern(?)

Do you get errors with (let [x 0] (ranged-rand x))? :pre and :post are ignored in release builds because they use assert.

Yes, I do get an error there (on compile).

Ah, good to know about ignoring :pre:/`:post`.

So then essentially I have to call (s/valid? x) manually in the fn definitions?

Welp, I have no idea. I just tried it with a (mostly) blank slate project with shadow-cljs. Just plain instrument + fdef is not enough to trigger any error during compilation. Are you sure you're seeing errors from spec and not warnings from compiler type/arity checker? And instrument + fdef is enough for me to get errors in run time. Even when calling an exported function from JS. (tested only development though)

(defn ^:export my-fn [arg]
  (println arg)
  1)

(s/fdef my-fn
        :args (s/coll-of string?)
        :ret integer?)

(st/instrument)

Oh it's actually a warning, you're right.

@U2FRKM4TW by the way the :export thing, is it still a thing? I've seen it around, but haven't found it mentioned with :target :esm which I'm using, I suppose it's only :target :nodexxx thing? Looks handy for debug.

No clue about :esm, I only use :browser. @U05224H0W should know.

@U2FRKM4TW OK, made it work with instrument. Thanks you 🙂

This is really more of a #C0AB48493 question since it's the thing that manages your dependencies. There should be a subcommand to output the full dependency tree (note that you should provide it with the same aliases you used when that warning showed up).

Ah, lein with-profile +profile1,+profile2 deps :tree.

Cool, that works. Thx. I had also found:

$ lein pom
$ mvn dependency:tree -Dverbose=true 

I have fixed this issue. see #137

If the pull request has not been merged for a long time, you can try to use [io.github.ruffnext/cljs-http "0.1.47"]

ps. Thanks, @U2FRKM4TW!

FWIW, I wouldn't use a third-party fork of unknown origin just because it's released. I'd rather seek a replacement for cljs-http (interop with JS is both easy and simple, and there's also cljs-ajax). Or, if you really need cljs-http, then I'd vendor it in, assuming its license allows you to do so.

Hmm, I used goog.net.Xhrio in my JS whos hiring project, might be a good idea. Thx! 🙏

Unless you really need that API, I'd use the things that are built into your browser. js/fetch has been around forever (in terms of JS) and all relatively modern browsers support it.

Hmmm, ChatGPT offers:

(ns my-namespace
  (:require [cljs.core.async :refer [<!]]
            [cljs.js :as js]
            [cljsjs.fetch]))

(defn fetch-get [url]
  (let [promise (js/Promise. (fn [resolve reject]
                              (let [headers (js-obj "Content-Type" "application/json")]
                                (js/fetch url headers)
                                (.then js/* this
                                       (fn [response]
                                         (when (.ok response)
                                           (resolve (.json response))))))
                              (fn [error] (reject error))))]
    (<! (js/await promise))))

It is completely wrong. I would not waste time with ChatGPT.

Yeah, had a feeling. It just occurred to me that, the way things are turning out, I can pull XHR out of Web/MX altogether. Let clients decide what to use. I'll take the easy way out in a separate examples replo, go with cljs-ajax.

I have a project on the latest shadow-cljs with :target :esm and I'm getting this code within deno repl when I load the generated code into it.;

It's rather annoying, I'm hoping to get rid off it, but I'm not understanding where is it coming from.

There's also #C6N245JGG

Right good point.

Never had to use Stripe but would not look past https://stripe.com/docs/js