Fork me on GitHub
#shadow-cljs
<
2020-05-15
>
kirill.salykin11:05:49

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"}}}
please advice how I fix it? thanks

thheller11:05:18

@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?

👍 4
thheller11:05:05

assuming shadow-cljs watch app is already running of course

kirill.salykin11:05:22

works, thanks a lot!

kirill.salykin11:05:09

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)
is this me doing something wrong?

thheller11:05:12

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

thheller11:05:50

$ 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=>

thheller11:05:53

works fine for me

kirill.salykin11:05:00

works for me as well now sorry for disturbing

kirill.salykin11:05:10

thanks, I’ll with fresh repl

folcon16:05:19

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.

thheller16:05:22

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

thheller16:05:28

I'll reverting that change though

thheller16:05:44

this was supposed to FIX dependency issues not add more

folcon16:05:29

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.

thheller16:05:50

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

thheller16:05:19

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

thheller16:05:49

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

folcon17:05:42

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

thheller17:05:01

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

thheller17:05:14

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

folcon17:05:14

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 :)…

folcon17:05:22

Thanks, I will do

thheller17:05:37

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

thheller17:05:03

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

thheller17:05:15

that did not exist in prior releases

thheller17:05:25

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

thheller17:05:28

so it breaks

thheller17:05:46

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

thheller17:05:55

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

thheller17:05:13

but of course nobody seems to do that

folcon17:05:59

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

thheller17:05:03

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.

folcon17:05:41

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.

lilactown17:05:33

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

thheller17:05:08

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

lilactown17:05:02

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

thheller17:05:53

well that is what the change was supposed to do

lilactown17:05:50

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

lilactown17:05:04

or something! just food for thought 😄

thheller17:05:32

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 😛

thheller17:05:52

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

thheller17:05:00

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

👍 8
haywood17:05:21

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)

thheller17:05:42

nope, not possible

haywood18:05:00

oh Thomas, ye have little faith

haywood18:05:20

(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})

haywood18:05:35

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)

haywood18:05:26

> no matter how awful

r20:05:07

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 🙂

r20:05:12

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

thheller20:05:34

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

r20:05:59

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

thheller20:05:34

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

thheller20:05:57

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

r20:05:06

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

thheller20:05:18

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

thheller20:05:33

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