hi I am trying to run a node-repl using instructions from https://shadow-cljs.github.io/docs/UsersGuide.html#repl-trouble-node but when I am node app/app.js - i dont see any WebSocket connected message - the scripts just runs main

{:deps true
 :builds
 {:app
  {:target :node-script
   :main 
   :output-to "app/app.js"}}}

@kirill.salykin I don't think the :node-script target prints anything anymore. if you don't get any errors it should just work? just call shadow-cljs cljs-repl app to get the REPL?

assuming shadow-cljs watch app is already running of course

let me try

works, thanks a lot!

something different: when I valuate (a/chan) (where a is clojure.async) i see this:

TypeError: Cannot read property 'call' of undefined
    at cljsEval (<eval>:1:30)
    at global.SHADOW_NODE_EVAL ([stdin]:105:10)
    at Object.shadow$cljs$devtools$client$node$node_eval [as node_eval] (/Users/kirill.salykin/.../.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/shadow/cljs/devtools/client/node.cljs:24:1)

I don't know. how did you get there? I mean what did you eval before that?

$ shadow-cljs node-repl
shadow-cljs - config: /mnt/c/Users/thheller/code/shadow-cljs/shadow-cljs.edn
shadow-cljs - connected to server
cljs.user=> (require '[clojure.core.async :as a])
nil
cljs.user=> (a/chan)
#object[cljs.core.async.impl.channels.ManyToManyChannel]
cljs.user=>

works fine for me

thanks, I’ll with fresh repl

If you’re running lein it appears that you have to install shadow-cljs globally?

./node_modules/.bin/shadow-cljs build :lambda
shadow-cljs - config: /<project-path>/shadow-cljs.edn
shadow-cljs - running: lein run -m shadow.cljs.cli --npm build :lambda
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Can't find 'shadow.cljs.cli' as .class or .clj for lein run: please check the spelling.
Syntax error (FileNotFoundException) compiling at (/private/var/folders/xl/rkkw077j4xxf827wn82mcp_c0000gn/T/form-init598900596536044588.clj:1:124).
Could not locate shadow/cljs/cli__init.class, shadow/cljs/cli.clj or shadow/cljs/cli.cljc on classpath.

no. you just can't use the npm version 2.9.3 with other shadow-cljs versions

I'll reverting that change though

this was supposed to FIX dependency issues not add more

Ah, sorry =)… I just saw there was an update, I’ve been using deps for the past few weeks, but needed to setup a lambda so just used lein as I’m more familiar with it.

it doesn't matter at all whether you use deps.edn or project.clj

the issue is that the npm shadow-cljs package 2.9.3 is only compatible with shadow-cljs CLJ 2.9.3. so you need to put that version into project.clj or deps.edn

but I'm pushing 2.9.4 now mismatched versions don't break anymore

Right, sorry I thought I’d double checked that, but I tweaked the update.

just update the npm install to 2.9.4 then everything should be fine again

doesn't hurt to update project.clj/deps.edn either though

The issue I was referring to was this line: running: lein run -m shadow.cljs.cli --npm build :lambda, I’ve not gotten around to installing shadow-cljs as global, so I was surprised that calling the npm installed one then triggered lein to run it as if it was global. Unless there’s some other stuff going on that I’m not aware of :)…

Thanks, I will do

you are not understanding the issue I'm trying to explain

I added a NEW namespace in 2.9.3 shadow.cljs.cli which the above it trying to call

that did not exist in prior releases

BUT you have an older shadow-cljs version specified in project.clj or deps.edn

so it breaks

so when you updated your global install and got 2.9.3 it started breaking

naive me thought people don't upgrade the npm package unless they also update project.clj/deps.edn

but of course nobody seems to do that

Yep, just tried that and you’re completely correct =)… Sorry for causing you stress @thheller!

my mistake really for calling the npm package the same name as the CLJ package. wish I could undo that but its too late for that.

It’s always tricky to work these things out ahead of time, fundamentally shadow-cljs is an excellent tool, and hopefully over time people internalise that this is how it works.

I’ve had an idea in the back of my mind of a tool that would help with generating & validating shadow-cljs.edn config

what would that do? the problem isn't in shadow-cljs.edn 😛

ah, sorry, I was reminded of it because it could also do some trivial validation of package.json + classpath

well that is what the change was supposed to do

yeah, a 2nd tool might allow us to use the same tool for multiple shadow-cljs versions and avoid the above. then you can instruct users to use the shadow-check tool to detect common errors

or something! just food for thought 😄

well the issue here is project.clj or deps.edn. I'm not going to attempt to parse those so there isn't really much that can be done 😛

the main issue is gone with 2.9.4 and all startup failures should now get enough info so people can figure out what to do

I'm not going to do any further help for project.clj or deps.edn related issues beyond the added error messages or user guide

I’m looking for any hack, no matter how awful, to work around the fact we can’t support dynamic imports, but this library I’m using uses them and I need to patch it. In my console I get Uncaught (in promise) Module not provided: ./assets/search.js I can’t tell if that’s something I can reroute via js-options (hasn’t worked thus far)

nope, not possible

oh Thomas, ye have little faith

(ns deli.utils.icon-hacks
  (:require ["@elastic/eui/lib/components/icon/assets/search" :as Search]
            [oops.core :refer [oset!]]))

(set! (.. js/window -EuiIconDict) #js {"search" Search})

modify the file in node_modules

_defineProperty(_assertThisInitialized(_this), "loadIconComponent", function (iconType) {
      Promise.resolve().then(function () {
        console.log("got here: ", iconType)
        return window.EuiIconDict[iconType];
      }).then(function (_ref)

lmao

> no matter how awful

hello—i’m currently building two CLJS npm-modules that are meant to be included in frontend webpack build to be consumed by a react app written in JS. i have them both building with shadow-cljs compile lib and they’re both npm linked into my frontend project. unfortunately, i get an error on load that makes a ton of sense: Uncaught Error: Namespace "goog.math.Long" already declared. because both packages are including the closure compiler and declaring that same module. is there a way to essentially declare the closure compiler as an extern so that it’s assumed that it will be available in the environment? or is there another solution to this i’m not thinking of? thanks 🙂

if this is a more general question for #clojurescript i can take it there as well

@robhanlon you should not be including two separate builds this way in one webpack build

alright! what’s the alternative? they’re currently completely separate shadow-cljs (and leiningen) projects—do i need to merge them?

you can turn them both into libraries and add a third that turns them both into one :npm-module build if you want

but you should always compile all CLJS sources you are going to use together. otherwise you'll end up including lots of duplicated code.

great. thank you so much for the help and the awesome project!

@haywood if you are going to rewrite the source code anyways you can just turn the dynamic import() into a require import or require

but yeah I'd strongly advise looking for another library 😛